CGI isn't a content type at all, it's a server extension
mechanism.
> > This works in theory, but is impractical because system resources
> > are limited and there is no guarantee the server can buffer all of
> > the chunked data.
>
> Certainly not in memory, but you're gonna need to have the request
> stored someplace to handle queueing of multiple jobs anyways.
And it's how CGI/1.1 is defined. No chunks need apply.
> > 2. Change CGI spec to remove dependency on CONTENT_LENGTH (and
> > change http servers accordingly).
>
> This has the potential for breaking a lot of CGIs that expect to see a
> CONTENT_LENGTH environment variable (assuming we get true HTTP/1.1
> browsers anytime soon).
It's not CGI/1.1, period. The CONTENT_LENGTH metavariable is
required, not optional. Which means the HTTP server *has* to
unchunk any chunked message-body before presenting it to a
CGI script.
Remember, the HTTP server is an intermediary between the CGI
and the client. If you want the CGI to include T-E semantics,
it needs to be defined for something later than CGI/1.1. I
invite you to join us at <http://Web.Golux.Com/coar/cgi/>;
right now we're finishing up the formal spec for CGI/1.1 and
will then use that as a basis for extending functionality
with CGI/1.2 -- or maybe CGI/2.0.
> Also, if you do a POST with a Content-Type
> of application/ipp (instead of application/x-cgi?), are you even
> following the CGI spec at all?
Eh? CGI is a mechanism, not a content-type. You can POST any
sort of content-type; if the server in question interprets
the target URI as something to be accessed through CGI, the
relevant information is passed to that CGI entity. What the
entity does with the content-body (which may be any IMT the
server permits) is up to it.
-- #ken P-)}Ken Coar <http://Web.Golux.Com/coar/> Apache Group member <http://www.apache.org/> "Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>