Re: Symantec LiveUpdate breaks squid.

Henrik Nordstrom wrote:
>
> Yes. Apparently it optimizes the request to a single RETR, skipping the
> CWD part.. Not entirely by the HTTP specification, but almost safe (it
> is safe for all known anonymous FTP...).

Not safe for authenticated FTP. And as you say, not by the spec.

> > Open FTP connection to update.symantec.com
> > USER cust-read
> > PASS Rcus-01#
> > CWD opt
> > CWD content
> > CWD onramp
> > RETR livetri.zip
>
> Yes, that is the specified behaviour if not optimized a single bit.

It must be *over* optimizing. If PWD was already /opt/content/onramp, the
CWDs would fail, but the RETR would succeed. Though only for paths under
the PWD. (or files in the PWD) The spec doesn't appear to define whether
the CWD failing should halt the request with an error, or not.

> > or:
> > Open FTP connection to update.symantec.com
> > USER cust-read
> > PASS Rcus-01#
> > RETR /opt/content/onramp/livetri.zip
>
> No. This is entirely different, and NOT according to the HTTP
> specification. The key issue is that in UNIX /opt which is not the same
> as opt (the first is a absolute UNIX path, the second is relative to the
> current working directory)

You are correct. I misread the fact that squid passes the path to ftpget
with the leading '/' intact. The spec infact states the '/' between the
hostname and/port and the rest of the path is *not* part of the path.
Should squid strip that before handing it to ftpget? The spec also mentions
that "//" should cause a CWD with a null argument. Currently ftpget
strips that also.

Still, if Squid/ftpget followed rfc1738 exactly, the URL should succeed.
The only way it should fail, is if the "CWD xxx" failure is supposed to
be passed back immediately, without completing any addition CWDs or the
actual RETR. The rfc1738 that I am looking at doesn't appear to address
error conditions. It is also a little ambiguous WRT the '#' in a password.
Initially it says that '#' is unsafe, and must always be encoded. I am
confused by an earlier paragraph that suggests that with the ftp scheme,
the hostname, directory, and file name are examples of octets that would
be subject to encoding. Further down it states the following:
   The user name (and password), if present, are followed by a
   commercial at-sign "@". Within the user and password field, any ":",
   "@", or "/" must be encoded.

This suggests to me that these are the *only* characters that need to be
encoded in the user & password field. Which would mean '#' unencoded
in the password field is perfectly valid.

-Andrew

-- 
-----------------------------------------------------------------
Andrew Gillham                            | This space left blank
gillham@whirlpool.com                     | inadvertently.
I speak for myself, not for my employer.  | Contact the publisher.