/../ in an http URL

> On the other other hand, a request for /../ is a bit wierd, because
> it's not clear that you are supposed to be able to do that

This is based on the assumption that an HTTP server should preserve
Unix file system semantics. I've looked through the RFCs a number of
times, and never found any support for this assumption.

RFC 1738 (for URLs) doesn't talk about the ".." path segment at all.

RFC 1808 does, but in the context of resolving relative URLs. Since
HTTP servers don't see relative URLs, this shouldn't apply.

The only thing I can conclude from this is that ".." as a path
component in a URL requested from a server is no different from any
other path component, and may be assigned whatever meaning the server
wants - including "up a directory level", "into the directory named
'..'" or "security violation".

I've seen the claim that this was a malformed URL. Not according to
either the BNF or the application semantics in 1738.

Possibly I'm missing one (or more) pieces of the puzzle. If this is
the case, I'd greatly appreciate know where to find them.

	Thanx,
	<mike

Received on Wednesday, 20 December 1995 17:57:00 UTC