On Mon, Nov 15, 2010 at 4:43 AM, Steven Simpson <ss@xxxxxxxxxxxxxxxx> wrote: > Hi, > > I intend to have a CGI program extract a form field and deliver this > data to an external system, but the field in question is likely to be > huge. The server can't invoke the program until it knows the length of > the request body, in order to set CONTENT_LENGTH in the program's > environment. If the POST doesn't include a Content-Length field, the > server will have to buffer the entire contents somewhere. Can it deal > with huge message bodies, such as those exceeding virtual RAM, by saving > to disc (for example)? mod_cgi/mod_cgid: request will fail with 411 if client doesn't send content-length; i.e., they don't have the logic to spool the body and compute CONTENT_LENGTH theoretically you could interject some other module to spool the body and set a computed content-length before the cgi handler runs > > How does FastCGI/fcgid compare? Will it handle huge POSTs any better? > My cursory reading of the FastCGI spec suggests that it doesn't have to > know the content length to deliver it, because it is sent in chunks. FastCGI spec indicates that CONTENT_LENGTH will be provided to the app, even though the request body will be sent to the application in chunks. Furthermore, it suggests that the app could compare CONTENT_LENGTH with the actual length received to determine if the client aborted before sending the entire body. mod_fastcgi: as with mod_cgi/mod_cgid: the request fails with 411 if the client doesn't send content-length mod_fcgid: request is fine if client doesn't send content-length, but application doesn't get CONTENT_LENGTH (bug) mod_fcgid spools the entire body to memory/disk before connecting to the app, so it should go ahead and pass over a computed CONTENT_LENGTH value; that would also resolve a Content-Length value from the client which becomes invalid because of a filter. So: mod_fcgid seems closest to what you need, and whether it works for you today is dependent on whether or not you need CONTENT_LENGTH set due to a chunked request body. --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|