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

Re: CGI???

From: David Robinson <drtr1@cus.cam.ac.uk>
Date: Tue, 21 Nov 95 18:21 GMT
Message-Id: <m0tHxKF-000DJKC@ursa.cus.cam.ac.uk>
To: mwm@contessa.phone.net
Cc: drtr1@cus.cam.ac.uk, www-talk@w3.org
> > >3) The CGI command line description has some serious errors. You don't
> > >get an argument only for ISINDEX query; not even according to this
> > >spec.
> > Yes you do; the spec _defines_ an ISINDEX query.
> 
> In which case I think the word "ISINDEX" is poorly chosen. The only
> other place I've seen it is as an HTML tag, which tag causes user
> agents to let users generate such queries. However, ISINDEX queries
> can also be generated by simple links (i.e. - the author included the
> query in the URL) and image maps.
> 
> Possibly calling it an "indexed" query would be less confusing.

Ok, I'll change the name.

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

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


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

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

>A comment that nscripts should send the status header first might be
>appropriate, or a warning about abusing the ability to not send it first.
Yes.

> >11) Amiga system-specific standards:
> Included.

> Please delete the comment about main(), argc & argv. AmigaDOS doesn't
> attach magic to the name main(), and doesn't provide an array of
> strings as arguments.

Ok.

> Actually, the magic of the main() procedure is C
> specific even on Unix. Other languages don't necessarily have a
> main(), and may not get the command line arguments as arguments to the
> initial procedure.

Hmm, that's a good point. (I never imagined a Fortran 77 CGI script, for
example.)

 David.
Received on Tuesday, 21 November 1995 13:22:10 GMT

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