Re: Is there a general or Squid specific FTP Proxy Protocol Spec?

Clemens Anhuth wrote:

> Okay.
>
> Does it make sense to put together an RFC for an FTP Gateway
> Protocol?

What makes sense it to put out an RFC defining the requirements for a
HTTP proxy acting on ftp:// objects, mapping HTTP actions to their FTP
actions. HTTP has a rather feature rich set of actions, but not exacly
the same as in FTP.

Note: HTTP->FTP gateway is a quite different thing. It is an application
publishing FTP content as HTTP content. The Squid implementation can be
used in this manner with the help of a redirector, but it is not it's
purpose. (i.e. user requests http://someserver/path/ and gets the
content of ftp://someotherserver/path/)

Note2: The goal of a HTTP proxy is NOT to act as a proxy for FTP
clients. It is to act as a proxy (or helping hand) for HTTP clients with
the capabilities expected by HTTP.

> Before I started out hunting for information that you can encode the
> action you want to be performed into the search args of your URL
> perhaps.
>
> something like...
>
> ftp://ftp.microsoft.com/BillGates?action=remove

Not really. URL's name an object, not actions on that object. Actions
are the commands performed on that URL, such as GET/PUT/DELETE/...

> As I understood all application gateways and firewalls implement
> their own brew. Is there no need for such a standard?

All HTTP proxies supporting ftp:// implements at least GET -> RETR.
Having an RFC showing that many other HTTP actions maps easily to FTP
would help to enrichen the capabilities of HTTP proxies and clients
using them for ftp:// objects.

What is not defined in any RFC today is how a HTTP proxy should render
FTP directory listings so each proxy has it's own method for doing so,
but on the other hand there is no RFC describing on a FTP server should
render directory listings either..

--
Henrik Nordstrom
Squid Hacker