Add directive to undo HEAD to GET mapping when output filters exist.

[GrahamDumpleton]

If Apache output filters are detected that could care about seeing the actual content for a HEAD, the mod_wsgi will remap a HEAD request to a GET request. This is to ensure that output filters will generate the same response headers where they are generating some based on the actual content. If this isn't done it is technically breaking the HTTP specification that response headers for GET and HEAD should be the same.

Even though this is the case, provide a directive to disable this auto mapping for those people who believe that they aren't using any Apache output filters where this would matter.

See:

• http://stackoverflow.com/questions/22443245/why-does-apache-wsgi-map-head-to-get-how-to-speed-up-head-in-flask/22444613

Original commentary about the GET vs HEAD problem at:

• http://blog.dscpl.com.au/2009/10/wsgi-issues-with-http-head-requests.html

[lrowe]

I have a need for access to the original request method when redirecting to resources on Amazon S3 using query string authentication. My current work around is set the original request method in a different environment variable:

SetEnvIf Request_Method HEAD X_REQUEST_METHOD=HEAD

Then fix up the wsgi environment in my app.

The only problem I've run into is when combining this with an internal redirect, as mod_wsgi sets request->method to GET. That makes sense for PUT or POST, but for HEAD internally redirecting to a HEAD would be more efficient for internal redirects to proxy locations. (Our files include multi-gigabyte raw sequence data.)

[GrahamDumpleton]

Can you try snapshot of mod_wsgi 4.3.0.

https://github.com/GrahamDumpleton/mod_wsgi/archive/feature/4.3.0.zip

Set the directive:

WSGIMapHEADToGET Off

This can be at VirtualHost scope, or more specific scope such as a Location or Directory block.

Just understand the consequences of doing this if an Apache output filter is present that expects to see the response content, even for a HEAD, to ensure that they match what would be returned for a GET request. If they don't match because of optimisations, then it can confuse caching systems.

[GrahamDumpleton]

Released in 4.3.0.