Re: a random thought

S Prabhakar wrote:

> A clarification on my previous mail...when i said
> ftp i didnt mean http-ftp i meant normal ftp
> [not ftp://.. :) ] i dont think this is already supported
> in squid...i have gone thru the documentation.
> squid supports only http ,http-ftp, wais, gopher etc..
>
> sorry for being vague...

Unfortunately this is very hard to do. I am not saying that is is
impossible, only that it is about 20 times harder than HTTP->FTP
gatewaying (this is what Squid does).

The reason: FTP does NOT define what happens when you do a CWD, and a
FTP session can be very complex.

Imagine the following FTP session (the [x] is object that we could
cache)

ftp some.server
login: anonymous
password: user@some.where
ftp> cd /pub
ftp> dir
ftp> cd something
ftp> dir
[http://]
ftp> binary
ftp> get somefile
[2]
ftp> cd ..
ftp> dir
[3]
ftp> cd somethingelse
ftp> dir
[4]
ftp> ascii
ftp> get anotherfile
[5]

If we would consider caching these, we have a number of problems. The
first one is to uniquely and securely tranlslate this to URL notation.

If we ignore the password used for anonymous connections, then this
translates to
[1]= ftp://some.server/%2fpub/something/;type=d
[2]= ftp://some.server/%2fpub/something/somefile;type=i
[3]= ftp://some.server/%2fpub/something/%2e%2e/;type=d
[4]= ftp://some.server/%2fpub/something/%2e%2e/somethingelse/;type=d
[5]=
ftp://some.server/%2fpub/something/%2e%2e/somethingelse/anotherfile;type=a

a) /;type=d can safely be optimized to /, but if injected into Squid the
listning needs to be translated to HTML.
b) ;type=[ai] can be removed if Squid uses the same mapping.
c) %2e%2e is needed. FTP does not define the directory name ".." to
anything special, and even on UNIX servers this can't be safely
optimized (we might have followed a symbolic link, making .. different).

This have a serious impact on the possible hit ratio, as the paths will
be very strange and changing.

Then there is some other pitfalls as well, but most of them are possible
to detect.

And given the percentage of FTP traffic, and that most FTP traffic is
from WWW clients (where proxying using a HTTP->FTP gateway is possible),
I don't se much point in even trying to implement something like this.

---
Henrik Nordstr�m
Sparetime Squid Hacker