[Web-SIG] HEAD requests, WSGI gateways, and middleware

[Graham Dumpleton]

On 25/01/2008, Brian Smith <brian at briansmith.org> wrote:
> 1. WSGI gateways must always set environ["REQUEST_METHOD"] to "GET" for HEAD requests. Middleware and applications will not be able to detect the difference between GET and HEAD requests.
>
> 2. For a HEAD request, A WSGI gateway must not iterate through the response iterable, but it must call the response iterable's close() method, if any. It must not send any output that was written via start_response(...).write() either. Consequently, WSGI applications must work correctly, and must not leak resources, when their output is not iterated; an application should not signal or log an error if the iterable's close() method is invoked without any iteration taking place.
>
> Please add this issue to http://wsgi.org/wsgi/WSGI_2.0.

This would go against how things are done with Apache and could cause
Apache to generate incorrect response headers for a HEAD request.

The issue here is that Apache has its own output filtering system
where filters can set headers based on the actual content. Because of
this, any output filter must always receive the response content
regardless of whether the request is a GET or HEAD. If an application
handler tries to optimise things and not return the content, then
these output filters may generate different headers for a HEAD request
than a GET request, thereby violating the requirement that they should
actually be the same.

Note that response content is still thrown away for a HEAD request, it
is just done at the very last moment after all Apache output filters
have processed the data.

Graham