Re: Native FTP proxying

On 09/04/2012 05:14 PM, Henrik Nordström wrote:
> tis 2012-09-04 klockan 16:29 -0600 skrev Alex Rousskov:
>
>> Why would "the second" approach be required by some? In other words,
>> what kind of FTP functionality the first approach cannot support? I do
>> not favor the second approach, but I would like to know what we are
>> losing by using the first approach (other than some performance).
>
> FTP is a rather messy protocol with many commands including site
> specific commands which can not be easily mapped to HTTP semantics
>
> And server state is also quite complex compared to HTTP.
>
> If you do
>
> cd /some/path/symlink
> cd ..
>
> then you end up in .. relative to the symlink, not /some/path/, which is
> a bit of a headache for mapping longer sessions.

Sure, but apart from keeping client and server connections related (via
the pinned connection API?), why would Squid care about this? It will
just forward the first CD command and then the second, relaying each
response to the client (all wrapped in a fake HTTP request while inside
Squid core). Squid does not need to understand the details of the
command semantics in this case or even keep "current directory" state,
right?

> On servers using drive names/letters state gets even messier as you then
> usually have one active path per drive. I.e. windows/dos and various old
> mainframe OS:es.

The same "Squid does not care" logic would apply there, it seems.

> But we do not need to cater for them all unless you plan on intercepting
> port 21. And even then most of the odd ones can be ignored if there is
> an acl to bypass interception on selected sites or users.

Agreed: There will probably always be cases where Squid has to care but
cannot handle some FTP specifics. It would be nice to have some specific
examples of those (the "cd" one above do not see to apply).

Thank you,

Alex.
Received on Wed Sep 05 2012 - 00:23:05 MDT