On Jan 3, 2011, at 10:39 PM, Graham Dumpleton wrote: > As documented in: > > http://blog.dscpl.com.au/2009/10/wsgi-issues-with-http-head-requests.html > > the automatic addition of a Content-Length response header where > len(iterable) is 1, can cause wrong output for cases where WSGI > application believes that it can itself decide not to return any > actual content for a HEAD response, ignoring the fact that there could > be output filters which rely on headers or content being exactly the > same as for GET. > > Do we therefore still want to promote the idea that the optimisation > is a good idea or even allowed?
I think it would be nice if it was allowed -- it makes simple apps easier. Just because some WSGI applications may be broken w.r.t. HEAD, that doesn't make this optimization undesirable. However, the current description does leave things a bit ambiguous. Why, for example, does it suggest only adding Content-Length if the length of the iterable is 1? Surely "if type(iterable) in (list, tuple)", the server could also set the Content-Length header to "sum(len(s) for s in iterable)". Is that forbidden, or just not explicitly spelled out as allowed? If your app *wants* to special-case HEAD handling so as to avoid generating the body when it doesn't need to, how can it do that correctly/reliably? If you normally return content with hard-to-determine length, and you want the HEAD processing to thus also omit Content-Length (and not, say, have the server decide it should return Content-Length: 0), what do you have to return to ensure this happens? James _______________________________________________ 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
