Re: CGI???

Mike Meyer (
Fri, 24 Nov 95 10:55:45 PST

> > Sure. I typically use PATH_INFO to locate a file on the server. If the
> > program is running on a system that allows "/" in file names, why
> > shouldn't I be allowed to use a file that has a "/" in the name? Or is
> > that to vague?
> That's not the sort of thing I had in mind.
> As a separate comment, if you _are_ on such a system, then you're out of luck.
> Presumably it has a heirarchical filesystem, with nested objects;

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

However, I still think that it should be recommended that
scripts/servers behave in the way that's easiest on each other.