Re: mod_cgi/1960: Apache - broken CGI interface?

[co...@apache.org]

[In order for any reply to be added to the PR database, ]
[you need to include <ap...@Apache.Org> in the Cc line ]
[and leave the subject line UNCHANGED.  This is not done]
[automatically because of the potential for mail loops. ]
[If you do not include this Cc, your reply may be ig-   ]
[nored unless you are responding to an explicit request ]
[from a developer.                                      ]
[Reply only with text; DO NOT SEND ATTACHMENTS!         ]


Synopsis: Apache - broken CGI interface?

State-Changed-From-To: open-feedback
State-Changed-By: coar
State-Changed-When: Mon Aug 31 14:39:36 PDT 1998
State-Changed-Why:

I wonder where the CGI++ people read that CGI/1.1
guarantees a Content-Length?  The only thing in this area
that I can recall (my references are not currently
available) is that if the method is POST then the script
needs to read no more than Content-Length bytes from the
input stream.  That should be extrapolated to apply to
any method the defined semantics of which include a
content-body.

It's a little unclear whether you're talking about input
to the script, or output therefrom.  For the former, the
CONTENT_LENGTH envariable should always be defined, even
if as a null string.

As for HTTP/1.1 and the lack of Content-Length..  IIRC that
only happens if the transfer-encoding is chunked, which
isn't supported for CGI anyway.

mod_cgi/1960: Apache - broken CGI interface?

[Nick Kew <ni...@webthing.com>]

> I wonder where the CGI++ people read that CGI/1.1
> guarantees a Content-Length?  The only thing in this area
> that I can recall (my references are not currently
> available)

Neither is mine, but I'm 99% certain it's in the old Robinson
draft, which is as near as we ever had to a formal spec.

> It's a little unclear whether you're talking about input
> to the script, or output therefrom.  For the former, the
> CONTENT_LENGTH envariable should always be defined, even
> if as a null string.

Shouldn't "0" be preferable to a null string?  (n.b. CGI++
treats them the same, but also logs an error if it gets null).

> As for HTTP/1.1 and the lack of Content-Length..  IIRC that
> only happens if the transfer-encoding is chunked, which
> isn't supported for CGI anyway.

IIRC it happens also when the browser loses the connection.
IMHO - for CGI/1.1 at least - it shouldn't call CGI at all when
the request is incomplete.

-- 
Nick Kew