Why? Not all servers have file systems underneath them. I don't have
experience with them, so I can't really comment on how they behave.
> for the URL http://host/script/foo%2fbar/baz
> the nesting of objects is clear; in the decoded PATH_INFO string
> /foo/bar/baz it is ambiguous.
What's ambiguous about it? Yes, if the script is interpreting
PATH_INFO with the semantics of the URL, you have a problem. I haven't
run into anything that says that PATH_INFO has to be interpreted that
way, though.
That's the real point - that PATH_INFO belongs to the script, and not
to the server, and most importantly not to the spec. I can understand
a server bouncing a request for security reasons of it's own - that's
part of the servers job. That the spec require that to happen seems a
bit excessive.
If this is going to stay in the spec as a requirement, the other
strings that have special meaning in the path part of a URL - "/./"
and "/../" ("//" is dealt with by the "/" restriction) all suffer the
same problem: if PATH_INFO decodes to something that include them, the
meaning is ambiguous.
> > But doing it the way you do it now *also* conflicts with existing
> > practice. That's why I recommended that it say "Should come first".
> > That makes the script work on more implementation.
> What existing servers require the CGI headers to come first?
Sorry. I meant that existing servers have hard limits on the number of
HTTP headers that can occur before the CGI headers. I also realized
that changes made elsewhere in the server make lifing this restriction
easy.
However, I still think that it should be recommended that
scripts/servers behave in the way that's easiest on each other.
<mike