wr...@apache.org wrote: > Author: wrowe > Date: Fri Jul 24 18:54:39 2009 > New Revision: 797603 > > URL: http://svn.apache.org/viewvc?rev=797603&view=rev > Log: > Remove hop by hop headers and set Connection: close to convince > all fastcgi consumers that they are not responsible for the various > processing which httpd has already performed, internally.
Folks, the patch inspires two questions; > Modified: httpd/mod_fcgid/trunk/mod_fcgid/mod_fcgid.c > URL: > http://svn.apache.org/viewvc/httpd/mod_fcgid/trunk/mod_fcgid/mod_fcgid.c?rev=797603&r1=797602&r2=797603&view=diff > ============================================================================== > --- httpd/mod_fcgid/trunk/mod_fcgid/mod_fcgid.c (original) > +++ httpd/mod_fcgid/trunk/mod_fcgid/mod_fcgid.c Fri Jul 24 18:54:39 2009 > - /* Remove some environment variables */ > - /* The Web server does not send CONTENT_LENGTH, PATH_INFO, > PATH_TRANSLATED, and SCRIPT_NAME headers */ > + /* Drop the variables CONTENT_LENGTH, PATH_INFO, PATH_TRANSLATED, > + * SCRIPT_NAME and most Hop-By-Hop headers - EXCEPT we will pass > + * PROXY_AUTH to allow CGI to perform proxy auth for httpd > + */ Do we want Proxy-Auth* headers to be shared with a CGI application? If so, howso, and if not, why not? Note this auth is hop-by-hop, and (in theory) httpd is both an endpoint, and a gateway to cgi which is allowed to do auth processing. > apr_table_unset(r->subprocess_env, "CONTENT_LENGTH"); > apr_table_unset(r->subprocess_env, "PATH_INFO"); > apr_table_unset(r->subprocess_env, "PATH_TRANSLATED"); > apr_table_unset(r->subprocess_env, "SCRIPT_NAME"); [these four above are not removed for the actual request _handler, but only when acting for the authn/authz mechanics.] > + apr_table_unset(r->subprocess_env, "HTTP_KEEP_ALIVE"); > + apr_table_unset(r->subprocess_env, "HTTP_TE"); > + apr_table_unset(r->subprocess_env, "HTTP_TRAILER"); > + apr_table_unset(r->subprocess_env, "HTTP_TRANSFER_ENCODING"); > + apr_table_unset(r->subprocess_env, "HTTP_UPGRADE"); None of the above should matter to the cgi; fastcgi protocol doesn't have a trailer mechanism for request bodies, so far as I'm aware. The request body Transfer Encoding, any upgrade or keep_alives should be ignored, and > + /* Connection hop-by-hop header to prevent the CGI from hanging */ > + apr_table_set(r->subprocess_env, "HTTP_CONNECTION", "close"); we should let the fastcgi app context consider itself 'done' upon completion of one request. I presume this is correct?
