William A. Rowe, Jr. wrote: > 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?
Thoughts?
