Re: Symantec LiveUpdate breaks squid.

Andrew Gillham wrote:
>
> David Luyer wrote:
> >
> > These two are not equivalent. What ftpget does is the same as the
> > standard intends. Note that the standard does "CD opt" not "CD /opt".
>
> They weren't supposed to be! The whole point is that Squid doesn't
> do any CDs before it tries to GET the file. If the standard is
> poorly written WRT ftp in the *real* world, then I understand if
> Squid doesn't work correctly.

Well. it is quite safe to do this optimization, at least for the server
in question....
CWD a
CWD b
RETR c
Is almost the same as
RETR a/b/c
when
RETR /a/b/c
is completely different.

And with respect to the URL standard (not HTTP as said before), it is
written with in depth thought on how the FTP protocol works. the FTP
protocol never defines / as a directory separator (with good reasons),
so relying on it as a fact in a standard is perhaps not so good... The
URL specification has a very well defined interpretaion for FTP type
URLs, as partially seen in the quotes below.

To make this more interesting, the URL standard defines
ftp://server
and
ftp://server/
to be the same thing, and as we all know this is not the case with
Netscape.. (in Netscape, the first one is a "redirect" to your home
directory, by using PWD, the second one is a CWD /, and the URL standard
even says that this / should NOT be regarded as a FTP path component,
since it is only a separator in the URL, separating the first path
component from the login part)

> If it means anything, Netscape's Proxy Server works
> *perfectly* with this URL, so I guess they don't follow standards.

They dont follow standards, and has never done. This is perhaps what
makes Netscape and Microsoft so much alike sometimes... ;-) Personally I
think this is very sad, but what can we expect from a company that have
not yet managed to to a decent interpretation of definition lists in
HTML... (I guess they are worried that if they change it to something
useful, it will break some web pages that has used DD and DT to control
the layout, often even outside DL...)

> > To access below your home directory you can do various things - one easy
> > thing is to provide a symlink 'root -> /' in the home directory; another
> > is to use ../../ (etc).
>
> This seems ridiculous. I don't need this with a real FTP client, with
> the Netscape Proxy Server, or with Netscape Navigator itself. Only when
> I go through a Squid server would I need this.

The Netscape navigator is known to do this wrong, and probably their
proxy server does the same thing which is even worse, but they probably
don't want to confuse their customers by doing something rigth once in a
while...

And yes. Using ../../.. is redicolous. Better use %2f instead... (and
the ../../ notation breaks in Netscape 3.x.. it thinks it is somekind of
relative URL, making a mess of it..)

> It isn't a webpage. It is a FTP URL. It is embedded inside their
> LiveUpdate software, which works fine directly, or via the Netscape Proxy
> Server. I haven't tested Apache yet, but perhaps I will.
>
> Regardless, there is still the problem of "#" in the password causing
> the URL to be truncated.

Yes, it is a problem, and can perhaps be regardes as a bug, but to be
formal # is not allowable in the password part, so it is perhaps better
to say it is a annoying feature ;-)
(see BNC definition in RFC 1738, defining password to be uchar ==
[a-zA-Z0-9$-_.+!*'(),] or %xx)

---
Henrik Nordström
------------------------------------------------------------------
Some quotes:
### STD 9 (RFC 765), File Transfer Protocol ### 
definition of pathname (line 270-275)
         Pathname is defined to be the character string which must be
         input to a file system by a user in order to identify a file.
         Pathname normally contains device and/or directory names, and
         file name specification.  FTP does not yet specify a standard
         pathname convention.  Each user must follow the file naming
         conventions of the file systems involved in the transfer.
Appendix II (about directory commands), a note on "pathname". line
3511-3516.
   The  "pathname"  argument should be created (removed) as a
   subdirectory of the current working directory, unless the "pathname"
   string contains sufficient information to specify otherwise to the
   server, e.g., "pathname" is an absolute pathname (in UNIX and
   Multics), or pathname is something like "<abso.lute.path>" to
   TOPS-20.
### RFC 1768, Uniform Resource Locators (URL) ###
3.2.2. FTP url-path
   The url-path of a FTP URL has the following syntax:
        <cwd1>/<cwd2>/.../<cwdN>/<name>;type=<typecode>
...
   The url-path is interpreted as a series of FTP commands as follows:
      Each of the <cwd> elements is to be supplied, sequentially, as the
      argument to a CWD (change working directory) command.
...
   Within a name or CWD component, the characters "/" and ";" are
   reserved and must be encoded. The components are decoded prior to
   their use in the FTP protocol.  In particular, if the appropriate FTP
   sequence to access a particular file requires supplying a string
   containing a "/" as an argument to a CWD or RETR command, it is
   necessary to encode each "/".
   For example, the URL <URL:ftp://myname@host.dom/%2Fetc/motd> is
   interpreted by FTP-ing to "host.dom", logging in as "myname"
   (prompting for a password if it is asked for), and then executing
   "CWD /etc" and then "RETR motd". This has a different meaning from
   <URL:ftp://myname@host.dom/etc/motd> which would "CWD etc" and then
   "RETR motd"; the initial "CWD" might be executed relative to the
   default directory for "myname". On the other hand,
   <URL:ftp://myname@host.dom//etc/motd>, would "CWD " with a null
   argument, then "CWD etc", and then "RETR motd".
....
3.2.4 Hierarchy
   For some file systems, the "/" used to denote the hierarchical
   structure of the URL corresponds to the delimiter used to construct a
   file name hierarchy, and thus, the filename will look similar to the
   URL path. This does NOT mean that the URL is a Unix filename.