I have applications that do detect the difference between a GET and a HEAD (they do slightly less work if the request is a HEAD request), so I suspect this is not a totally reasonable thing to add to the spec. Maybe instead the middleware that does what you're describing should be changed instead to deal with HEAD requests.
In general, I don't think is (or should be) any guarantee that an arbitrary middleware stack will work with an arbitrary application. Although that would be nice in theory, I suspect it would require a very complex protocol (more complex than what WSGI requires now). - C Brian Smith wrote: > My application correctly responds to HEAD requests as-is. However, it doesn't > work with middleware that sets headers based on the content of the response > body. > > For example, a gateway or middleware that sets ETag based on an checksum, > Content-Encoding, Content-Length and/or Content-MD5 will all result in wrong > results by default. Right now, my applications assume that any such gateway > or the first such middleware will change environ["REQUEST_METHOD"] from > "HEAD" to "GET" before the application is invoked, and discard the response > body that the application generates. > > However, many gateways and middleware do not do this, and PEP 333 doesn't > have anything to say about it. As a result, a 100% WSGI 1.0-compliant > application is not portable between gateways. > > I suggest that a revision of PEP 333 should require the following behavior: > > 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. > > Regards, > Brian > > _______________________________________________ > Web-SIG mailing list > Web-SIG@python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: http://mail.python.org/mailman/options/web-sig/chrism%40plope.com > _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
