Chris McDonough wrote: > 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.
Yes, of course. In order to avoid doing unnecessary work for a HEAD request, the extra work needs to be transferred to the response iterable; for a HEAD request, the gateway would skip the iterable except for its close() method, and so all the extra work is skipped as well. > Maybe instead the middleware that does what you're describing should be changed > instead to deal with HEAD requests. I agree. But, this problem is often overlooked by middleware, which indicates that we at least need an explanation of the problem in the specification. But, when the middleware are corrected, then applications like yours will only work efficiently if they transfer the extra work they do for GET (vs. HEAD) requests to the response iterable. > 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). That is exactly what WSGI is designed for. There is no point to having a standard if there is no interoperability amongst compliant components. - 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/archive%40mail-archive.com