[Web-SIG] HEAD requests, WSGI gateways, and middleware
ianb at colorstudy.com
Fri Jan 25 04:30:50 CET 2008
Brian Smith wrote:
> Graham Dumpleton wrote:
>> 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.
> Right, that is exactly what I am saying. In Apache's documentation, it
> says that every handler should include the response entity for HEAD
> requests, so that output filters can process the output. However, there
> is nothing in PEP 333 that talks about this behavior.
Unlike Apache there are no output filters in WSGI; all middleware gets
to adjust the request as well as the response. So middleware that can't
handle a real HEAD request has an opportunity to turn it into a GET
request. I don't see why PEP 333 needs to talk about this, to me it
seems straight forward enough in a WSGI context, and PEP 333 can't cover
every possible bug someone might introduce into their middleware.
More information about the Web-SIG