On Mon, Nov 15, 2010 at 4:25 PM, William A. Rowe Jr. <wrowe@xxxxxxxxxxxxx> wrote: > On 11/15/2010 3:43 AM, Steven Simpson wrote: >> >> 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)? >> >> 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. > > This is really a flaw in your CGI; it should read to end of stream (httpd > will mark that stream EOF when it's complete under either cgi or fastcgi) > and if it wants to read it all into memory (hopefully with some limits > imposed based on realistic expectations) then it's free to buffer. > httpd will avoid buffering entirely, whenever it is possible. It isn't > httpd's job to be buffering as a developer convenience. It can be very useful for httpd/mod_foo to buffer request/response bodies to restrict the number of application processes in use at any one time, when they are more expensive than httpd threads. --------------------------------------------------------------------- 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