mod_proxy_ftp relative directory bug

[Jon Snow <js...@gatesec.net>]

Hi,

I am running forward proxies using 2.2.0 and 2.2.2. Using diff I have 
determined there are no differences in the mod_proxy_ftp.c files related to 
the following.

When going to an ftp site:

ftp://ftp.example.com/dir1/dir2

mod_proxy_ftp determines a directory exists through the SIZE command and 
updates the "Directory of" HREF accordingly. The browser is unsure whether 
the dir2 is a file or directory so it's base_href location stays at:

ftp://ftp.example.com/dir1/

The relative HREF directories and files returned in the directory listing of 
ftp://ftp.example.com/dir1/dir2 are subsequently relative to ftp://
ftp.example.com/dir1/ and they break in the client browser. This occurs when 
a site provides a URL ending in a directory without a trailing slash to a 
user and the user clicks directly on it. Tested using late IE and Firefox.

In http a redirect would have been returned to the browser with a trailing 
slash once the directory is detected. Should the ftp proxy also return a 
redirect with a trailing slash at the point it has determined a directory 
exists?

e.g. ftp://ftp.example.com/dir1/dir2 -> 302 ftp://ftp.example.com/dir1/dir2/

Regards,
Jon Snow

Re: mod_proxy_ftp relative directory bug

[Jon Snow <js...@gatesec.net>]

Nick,

> What do you mean by 'updates the "Directory of" HREF accordingly'?
> Are you trying to say mod_proxy_ftp requests a *different* URL from
> the origin server?  If so, it sounds like a bug.

I am saying that the returned directory listing heading has the corrected path 
with the trailing slash but this heading is purely information from a users 
point of view. The proxy at this point knows what the correct path should be 
but does not inform the client either by redirect or adjusting the directory 
listing to have relative paths of the form:

dir2/somefile.txt

The proxy does request the same URL from the origin server as typed by the 
client then determines through a series of ftp commands whether it is a 
directory or file.

> That correction, in either http or ftp, is the business of the origin
> server, not the proxy.  For a proxy to issue it would be deeply broken.

Problem is the origin server speaks ftp but the client speaks http. The proxy 
needs to intervene on the clients behalf and convert the ftp response to an 
http response that the user can 'web browse'. It is the same as the proxy 
converting the client's http GET request into an assortment of ftp commands 
that the origin server can understand.

Regards,
Jon

On Wednesday 23 August 2006 00:45, Nick Kew wrote:
> On Tuesday 22 August 2006 12:26, Jon Snow wrote:
> > When going to an ftp site:
> >
> > ftp://ftp.example.com/dir1/dir2
> >
> > mod_proxy_ftp determines a directory exists through the SIZE command and
> > updates the "Directory of" HREF accordingly.
>
> What do you mean by 'updates the "Directory of" HREF accordingly'?
> Are you trying to say mod_proxy_ftp requests a *different* URL from
> the origin server?  If so, it sounds like a bug.
>
> > The browser is unsure whether
> > the dir2 is a file or directory so it's base_href location stays at:
> >
> > ftp://ftp.example.com/dir1/
>
> That's entirely right if the server didn't issue a redirect.
>
> > In http a redirect would have been returned to the browser with a
> > trailing slash once the directory is detected. Should the ftp proxy also
> > return a redirect with a trailing slash at the point it has determined a
> > directory exists?
>
> That correction, in either http or ftp, is the business of the origin
> server, not the proxy.  For a proxy to issue it would be deeply broken.

Re: mod_proxy_ftp relative directory bug

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Nick Kew wrote:
> 
> That correction, in either http or ftp, is the business of the origin server,
> not the proxy.  For a proxy to issue it would be deeply broken.

Not really.  Consider the semantics of FTP.  FTP can serve a 'directory' with
LIST or NLST, but I'd only want that to be in response to /dir1/, not /dir1
since the later is pretty ambiguous.

But FTP has no concept of redirects, so your assertion that the FTP origin
server is responsible for a redirect is silly.  It doesn't follow web URI
conventions, so 'fitting' an FTP server into the role of a URI resource is
the job of the FTP client, or the HTTP proxy layer for an HTTP client.

I'd personally agree that if we know /dir1 is a directory resource, we should
probably teach mod_proxy_ftp to provide the /dir1/ redirect.

Re: mod_proxy_ftp relative directory bug

[Nick Kew <ni...@webthing.com>]

On Tuesday 22 August 2006 12:26, Jon Snow wrote:

> When going to an ftp site:
>
> ftp://ftp.example.com/dir1/dir2
>
> mod_proxy_ftp determines a directory exists through the SIZE command and
> updates the "Directory of" HREF accordingly.

What do you mean by 'updates the "Directory of" HREF accordingly'?
Are you trying to say mod_proxy_ftp requests a *different* URL from
the origin server?  If so, it sounds like a bug.

> The browser is unsure whether 
> the dir2 is a file or directory so it's base_href location stays at:
>
> ftp://ftp.example.com/dir1/

That's entirely right if the server didn't issue a redirect.

> In http a redirect would have been returned to the browser with a trailing
> slash once the directory is detected. Should the ftp proxy also return a
> redirect with a trailing slash at the point it has determined a directory
> exists?

That correction, in either http or ftp, is the business of the origin server,
not the proxy.  For a proxy to issue it would be deeply broken.

-- 
Nick Kew