Does anyone consider this response acceptable?
127.0.0.1 - - [05/Mar/2001:09:49:11 -0600] "HEAD
/manual/misleading-insulting-statement/../suexec.html HTTP/1.0" 200 0
It's possible, due to our current parsing schemas (1.3/2.0) to serve a given
resource with a very misleading URL name. I'd argue that this should generally
be a redirect, to address the above PR. First, it violates Roy's assertions
that we shouldn't fill up the proxies' namespace with cruft, and second, it
makes it possible for very misleading names to link to the site.
[Note on Win32 that two [or more] dots is the parent directory, since ambigious
trailing periods are truncated when names are resolved. (.+)\.* == $1]
The same logic probably applies to /./ or // and since most clients resolve these
issues themselves (when constructing relative links) I'd propose we always redirect
on all of these requests. Since this introduces potential issues for DAV, among
other things, I'm posting before authoring a patch. If we can't tollerate the
potential to break other apps, I'd suggest we also allow this to be toggled, in the
same [new?] directive as the EtagInode directive.
I'm thinking FilesystemOptions [[+|-]EtagInode] [[+|-]CanonicalRedirect]
I'm not advocating that we hit the filesystem to validate the resources we '..' out of.
That would be far to costly, and the basis for DNS attack.
Bill
