A few comments on this. The first is that mod_wsgi originally never allowed its WSGIPassAuthorization directive in a htaccess file, and then when it it did first allow it, it was only honoured if AuthConfig was allowed for that context.
I kept having people who needed that ability when they had a htaccess file, but didn't have AuthConfig. One of the things that was pointed out was that if you have htaccess enabled, and mod_rewrite was being loaded into Apache, you could get access to the Authorization header anyway. RewriteEngine on RewriteBase / RewriteCond %{HTTP:Authorization} ^(.*) RewriteRule ^(.*)$ $1 [e=HTTP_AUTHORIZATION:%1] In the end, since mod_wsgi arguably shouldn't ever be used in shared environments anyway, I ended up caving in and allowing WSGIPathAuthorization in htaccess to make it convenient for the more typical scenario that kept coming up. Now having the ability within mod_wsgi for a web application to handle authorisation this showed up a couple of problems in the ap_scan_script_header_err_core() function. This arose because the response data when it comes back from a mod_wsgi daemon process just users the CGI way of doing things and so used that function. The first problem was that when WWW-Authenticate headers came back in a response, the ap_scan_script_header_err_core() function would merge the values of multiple instances of such headers with a comma in between the values. As a result, a single header would get returned back to the HTTP client. As with Set-Cookie header, this would cause problems with some HTTP clients and they would fail due to the merging. More recent versions of mod_wsgi therefore no longer use ap_scan_script_header_err_core() and have had to duplicate what it does so as to prevent merging of WWW-Authenticate headers. The second problem was the size limitation on the values of the headers coming back from a CGI script. As is, the complete header name and value must fit within MAX_STRING_LEN (8192). If the size didn't fit under that, you would from memory get the cryptic error message of 'Premature end of script header'. In recent times, application such as OpenStack KeyStone have been generating values for the WWW-Authenticate header which are larger than MAX_STRING_LEN and so they were failing when used with mod_wsgi because of the use of ap_scan_script_header_err_core(). In recent versions of mod_wsgi, the buffer size used to read the header name and value defaults to 8192, but can be overridden through a configuration option to allow a larger value to come back. So irrespective of where you are going to allow this CGIPassHeader directive, you might want to look at these other two issues, and if not both, certainly the issue of WWW-Authenticate being merged as it will cause issues for some browsers if someone ends up passing back multiple WWW-Authenticate headers as I am told it can if it supports a choice of authentication schemes. Graham On 17 August 2014 06:16, Jeff Trawick <traw...@gmail.com> wrote: > This core directive would be used to modify the processing of > ap_add_common_vars() to pass through Authorization or Proxy-Authorization > as HTTP_foo. (Nothing else is currently blocked, so any other header name > wouldn't make sense.) > > This directive would be configurable at the directory level, but not in > htaccess. > > Various mods (mod_fastcgi, mod_fcgid, mod_wsgi, etc.) have ways to pass > this information through; bug 56855 has a patch to add it to mod_proxy_fcgi > too. With that patch in place, at least mod_proxy_scgi in our tree still > couldn't front an app that wants to handle Basic auth. It would be good to > consolidate over time the code/documentation around suppressing > *Authorization. > > Some concerns: Processing it in ap_add_common_vars() is not finely scoped > to natural users of the data; e.g., mod_include and mod_ext_filter would > see it. At the same time, not allowing it in htaccess may negate its > usefulness in some environments. > > Thoughts? > > -- > Born in Roswell... married an alien... > http://emptyhammock.com/ > >