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 _______________________________________________ Web-SIG mailing list [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
