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

[Graham Dumpleton]

On 4 January 2011 15:43, James Y Knight <foom at fuhm.net> wrote:
>
> 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?

It just doesn't mention it. From memory it also doesn't mention what
to do about case when len(iterable) is 0 either, which presumably if
such an optimisation was allowed could allow you to set Content-Length
to 0.

> 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?

Which is further support for the WSGI server not making decisions
itself to set Content-Length. But then, if an application isn't going
to generate Content-Length for HEAD, then it can't by rights do it for
GET either for same request else the response headers are different.

Graham