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.
Then the middleware is just wrong. It shouldn't overwrite ETag values generated by the application, and if it is set to generate ETags from hashes of the content then it should change HEAD to GET. > 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. Nothing in WSGI says that all middleware is sensible or correct. In this case it just seems like there's a bad middleware involved that isn't respecting basic HTTP semantics. WSGI doesn't specify HTTP semantics but of course they are a basic foundation for any kind of interaction, and it's assumed they'll be respected. Ian _______________________________________________ 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