Yup, we ran into this, too. The solution with our HTTP server
"engine" was to send chunked POST data to a file and then set the
CONTENT_TYPE environment variable to the final data/request size.
This is probably what Acme and Jigsaw do.
IIRC, POST != CGI, as CGI is just one possible content type.
> ...
> 1. No spec changes. HTTP/1.1 servers that don't support chunked
> POSTs are considered broken, and have to be fixed to buffer a
> chunked request message-body in order to generate a CONTENT_LENGTH.
How many IPP implementers are using an existing HTTP server?
> 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.
> It's also inefficient. For example, for IPP with chunked encoding,
> the printer could begin printing a job while the request is still
> arriving if the request didn't have to be buffered in the http
> server.
Will HTTP servers in printers need to handle a normal CGI interface,
or will everything be handled by internal "functions"? If the latter
then the whole chunked POST issue isn't important.
> 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). 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?
-- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com