[Web-SIG] Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

[James Y Knight]

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