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 [EMAIL PROTECTED]
