Squid Web Cache wiki

Squid Web Cache documentation

๐Ÿ”— Feature: Native FTP proxying

๐Ÿ”— Functionality

This project adds an ftp_port option to squid.conf. Squid acts as an FTP-to-FTP gateway for TCP traffic sent to that port:

  1. Squid listens for native FTP requests sent to the configured port.
  2. Squid converts received FTP commands to internal HTTP wrapper requests,
  3. Squid forwards those internal requests from the client to server side (while subjecting them to access controls and optional content adaptation, as usual)
  4. In the future, Squid may even forward those HTTP wrapper requests to peers, but that functionality is outside the initial implementation scope.
  5. On the server side, Squid converts HTTP wrapper requests to FTP commands, forwarding those commands to the FTP server.
  6. Similarly, FTP server responses are forwarded back to the FTP client, wrapped in HTTP responses.
  7. Squid logs the FTP transaction using HTTP wrappers and existing access logging code.

๐Ÿ”— Mapping

๐Ÿ”— FTP command to HTTP request mapping

Each FTP command, whether understood by Squid or not, is mapped to an HTTP request.

HTTP Request property Mapping algorithm
Request method โ€œPUTโ€ for FTP STOR. Otherwise GET?
Request URI ftp://host/ (for now; see Future Enhancement)
Request protocol and version HTTP/1.1 (That is what these wrapper messages are to Squid core. Also, some ICAP services may fail on FTP/x.y)
Host header FTP server name followed by non-standard port if any
FTP-Command FTP command name
FTP-Arguments FTP command arguments (i.e., everything after the FTP command name and before CRLF). Not present if CRLF follows command name. Present but empty of SP CRLF follow command name.

๐Ÿ”— FTP reply to HTTP response mapping

HTTP Response property Mapping algorithm
Response status code and reason phrase 100 Continue for any grokked FTP 1xx response; 200 OK for any other grokked FTP server response; 500 Server Error otherwise
Request protocol and version HTTP/1.1 (so that ICAP services do not fail on FTP/x.y)
Date FTP reply start date
Cache-Control โ€œprivateโ€ (Squid cannot cache these until we track Request URIs)
Content-Length none if there is an associated file transfer; zero otherwise
FTP-Status FTP reply code (e.g., 431)
FTP-Reason FTP explanatory text (e.g., โ€œNo such directoryโ€)

๐Ÿ”— Mapping of FTP body transfer

Squid does not forward HTTP bodies using HTTP constructs internally. The code will have to use existing Squid body forwarding APIs (BodyPipe for request bodies and Store for response bodies).

๐Ÿ”— Transfer failures

Terminate body transmission as in the case of HTTP body transmission failure. In case of reply body, send an 1xx control message to the client side indicating the final FTP status code.

๐Ÿ”— Mapping example

Label FTP-C Squid-C FTP-S Squid-S
Sends what FTP command HTTP Request FTP reply HTTP response
sender(s) and receiver(s) client to Squid Squid client-side to server-side server to Squid Squid server-side to client-side
Squid to server Squid to client ย  ย  ย 
 FTP client <--> Squid Squid client-side <--> Squid server-side Squid <--> FTP server
 ------------------------------- ------------------------------------------ -------------------------------
 USER anonymous@ftp.example.com 
 GET ftp://ftp.example.com/ HTTP/1.1
 Host: ftp.example.com
 FTP-Command: USER
 FTP-Arguments: anonymous@ftp.example.com
 USER anonymous@ftp.example.com
 331 User name okay, need password.
 HTTP/1.1 200 OK
 Date: ...
 Cache-Control: private
 Content-Length: 0
 FTP-Status: 331
 FTP-Reason: User name okay, need password.
 331 User name okay, need password.
 RETR test.gz
 GET ftp://ftp.example.com/ HTTP/1.1
 Host: ftp.example.com
 FTP-Command: RETR
 FTP-Arguments: test.gz
 RETR test.gz
 150 File status okay; about to open data...
 HTTP/1.1 100 Continue
 Date: ...
 Cache-Control: private
 FTP-Status: 150
 FTP-Reason: File status okay; about to open data...
 150 File status okay; about to open data...

๐Ÿ”— Logging

Individual FTP transactions (commands and replies) are logged as HTTP transactions (with HTTP-specific information missing) and using existing access logging facilities. The following details should be available in the access log:

Note that Squid does not map FTP status codes to HTTP status codes in HTTP wrapper messages so FTP and/or logging code may need to adjust logged values to reflect the true FTP status and not the HTTP status of the wrapping HTTP message.

๐Ÿ”— Future enhancements

One very useful but difficult to support feature is tracking of FTP current or requested directory across CD and similar commands. Such tracking would allow simple access controls based on request URIs. While primitive tracking is not very difficult to support, FTP directory links make proper support very tricky (and impossible in some cases): In FTP, โ€œfoo/bar/..โ€ path (i.e., a sequence of โ€œCD fooโ€, โ€œCD barโ€, and โ€œCD ..โ€ commands) may result in current location different than โ€œfooโ€ (i.e., the โ€œPWDโ€ command will not print โ€œfooโ€). Eventually, Squid will probably track the URI using one or more algorithms, but this project does not include such support or the decision which URI tracking algorithm to implement.

Categories: Feature

Navigation: Site Search, Site Pages, Categories, ๐Ÿ”ผ go up