Reorganized FTP response storage/wrapping to fix multi-line response gatewaying
Multi-line FTP control responses use various line prefixes to tell the client
that the response continues to the next line. Some multi-line responses use a
"CODE-" line prefix. Some, like FEAT, must use a single space as a line prefix
(except for the first line that uses "CODE-"). Squid was removing the virgin
prefix and then using "CODE-" prefix for all lines, breaking FEAT and probably
other responses.
While modifying original multi-line prefix was a bad idea, leaving FTP
multi-lines "as is" does not work either because HTTP wrapping removes leading
spaces which are significant in FEAT and other FTP responses.
Squid now preserves leading multi-lines by wrapping them using quoted strings.
Adaptation services wishing to interpret multi-lines must unquote any quoted
FTP-* header field values before adaptation and return quoted values back (if
needed). Which FTP-* header values are quoted and which are not may be
value-dependent and may change. Quoting and unquoting requires handling of
HTTP \-CHAR escape sequences.
The last FTP response line has to be treated specially because it has [more]
strict syntax, has to be interpreted by Squid, subjected to squid.conf ACLs,
and is more likely to be adapted. Squid used to wrap all multi-lines into
multiple fields of an FTP-Reason header while only storing the "reason" from
the last multi-line there. That was messy, and became prohibitively so when
multi-line quoting of multi-lines was introduced.
Now Squid wraps all multi-lines except the last one using FTP-Pre header. All
FTP-Pre lines may be wrapped as quoted strings. FTP-Status and FTP-Reason
headers are used for the FTP code and reason phrase from the last line:
FTP-Pre: "123-first line"
FTP-Pre: " second line"
FTP-Status: 123
FTP-Reason: from the third line
Needs more work if there are adaptation services that merge multiple FTP-Pre
header values together.