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

Ian Bicking 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.

   Ian


More information about the Web-SIG mailing list