Re: CGI???

> > > >...
> > > > It's nothing to do with the file system semantics; the semantics of a
> > > > URL use unencoded / as a path component separator. If you decode
> > > > encodeded '/', then you would incorrectly change the semantics of the
> > > > URL.
> > > Hmm - possibly this should be broadened a little bit, allowing the
> > > server to send a 404 error if the PATH_INFO or SCRIPT_NAME fields look
> > > to be a security problem as far as the server is concerned. This would
> > > make such behavior implementation dependent. I can see wanting both
> > > the server to protect you from this (and deal with ".." & etc. things,
> > > as someone else suggested) and wanting the server to not fool with
> > > things.
> > Hmm, maybe; I'm not yet convinced. Can you think of a concrete example?
> 
> 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; 
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.

> > > In practice, there's going to be a limit. Requiring
> > > the CGI headers to be first solved this problem.
> > But it would conflict with existing practice.
> 
> 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? 

> > > >11) Amiga system-specific standards:
> 
> Maybe I should stop on this until things settle down more? Anyway, the
> current directory is the script directory for existing amiga servers.

No, don't stop. 8-)

 David.

Received on Friday, 24 November 1995 13:32:49 UTC