Re: lynx-dev LYNX: meaning of "Bad partial reference; stripping

[Klaus Weide]

On Fri, 28 Jul 2000, David Woolley wrote:

> > . and .. *are* hard links, modulo the magic that happens at device 
> > boundaries 
> > on unicies.  A direct effetc of this is that you can compute hte number of 
> 
> However, in HTTP URLs, they do not have this meaning.  The only guaranteed

Exactly.  Resolution of relative URLs is a purely string-based operation,
it has nothing to do with "hard links", "devices", etc.

> semantics are that, when left to right scanning the concatenation of
> the base URL, with everything after the last / (home pages strictly
> have a trailing one), .. causes the deletion of right most remaining /
> delimited component.  Excess ..'s do not cause the deletion of the site
> name, but nor are they ignored.  They are simply illegal.  However,

Whether they're illegal or not depends on the server.  There is nothing in
the protocol that prevents "http://some.server/../somepage.html"; from
being a valid absolute URL, and a server may choose to accept this and
map it to a resource (which might be different from any other including
"http://some.server/somepage.html";).  It wouldn't be wise, of course -
becausee of the comon error recovery mentioned below, for one thing.

> they are so common that standard browser error recover is to delete them
> without cancelling any component of the URL.  I can't remember how . is
> handled, but, if it has a special meaining, it is rarely used.
> 
> The rules for FTP URLs may be different, as they assume a file system,

Resolution of relative URLs isn't different for FTP URLs.

> not an abitrary hierarchical name space.  I'd need to check, but I think
> excess ones are passed through, and each one should cause the server to
> change one directory up.  I'm not sure if internal ones are collapsed by
> the browser; even on Unix, the results of these two options can differ.
> 
> In particular, FTP URLs are not directly filenames.  The server must behave
                                                           ======
> as though e.g. / delimited component before the last caused a single step
> in the directory tree.  In some cases this may be the same as just using
> the name, but not always.

Replace "server" -> "client".  The server doesn't see URLs, just a series
of requests that involve filenames or path components.  (At least that's
how it should be.)

 Klaus


; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden