W3C home > Mailing lists > Public > www-talk@w3.org > November to December 1995

Re: CGI???

From: Mike Meyer <mwm@contessa.phone.net>
Date: Tue, 21 Nov 95 11:07:48 PST
Message-Id: <19951121.7767A68.A5C3@contessa.phone.net>
To: www-talk@w3.org
> > > >6) Under requirements for servers, you say:
> > > >        Servers should reject with error 404 any requests that would
> > > >        result in an encoded "/" being decoded into PATH_INFO or
> > > >        SCRIPT_NAME.
> > > >Why? Remember that the justification can't include the semantics of
> > > >the underlying file system.
> > > 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?

> > > >7) The "Data input", and "Data output" requirements should be
> > > >appreciably tightened, to indicate that servers should tie the default
> > > >input and output streams to the incoming object and output to the
> > > >client. Since it may not be possible, we can't require it. But that's
> > > >the desired behavior if it's possible.
> > > I don't think it is desirable, except in the case of nph scripts.
> > > Otherwise, the server is restricted to HTTP/1.0-style single requests
> > > per connection. If the server is allowed to buffer script input and output,
> > > then it can support multiple requests per connection even for CGI scripts.
> > Now, pull that thought I asked you to hold. Are there any existing CGI
> > implementations that don't use the standard I/O streams? Are there any
> > existing CGI applications that won't break on a server that chooses
> > not to implement the two streams in that way? This also breaks
> > existing applications....
> No and no. But you misunderstood; I wasn't suggesting not using standard I/O
> streams; I was suggesting that the standard I/O streams _not_ be required
> to be on top of file descriptors for a Unix socket connection to the client,
> i.e. I want to allow the I/O streams to be pipes to the server process only.

Ah, that I agree with - it's not clear that all systems can support
the socket/stream duality that unix does. I still think the "Unless
otherwise specified, this will" should be replaced by "This should",
but that's a minor point.

 > > > >8) You've made a quiet change to the behavior of parsed headers -
> > > >requiring that the CGI headers appear before the HTTP headers. A good
> > > >idea, but this should be noted.
> > > Not intentional; I'll correct this. Thanks.
> > There's a problem with this version. The server can't send any data
> > until the Status: header has been seen. This means the server has to
> > save the potentially unlimited set of HTTP headers until the status
> > header is seen.
> That is intentional. It is how current servers behave; they do not requre
> the Status line to come first. In practice, it is not a problem. The script
> will probably send fewer headers than the client did, and the server saved
> all those headers.

Why do people keep refering to this? Is there something I missed in
the spec that requires the CGI header handling & HTTP header handling
to be the same code? As far as I can tell, there's no requirement that
they be part of the same binary. Since I implemented CGI via the
external module API, they aren't.

> > 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. You might also want
to say that the CGI implementation "should be prepared to handle an
arbitrary number of HTTP headers before the status" for the same
reason.

> > >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.

	Thanx,
	<mike
Received on Tuesday, 21 November 1995 14:15:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:18 GMT