[Web-SIG] PEP 444 (aka Web3)

[Matt Goodall]

On 20 September 2010 16:19, Robert Brewer <fumanchu at aminus.org> wrote:

> > On Sun, 2010-09-19 at 21:52 -0400, Chris McDonough wrote:
> >
> > > I'm -0 on the server trying to guess the Content-Length header.  It
> > just
> > > doesn't seem like much of a burden to place on an application and
> > it's
> > > easier to specify that an application must do this than it is to
> > specify
> > > how a server should behave in the face of a missing Content-Length.
> > I
> > > also believe Graham has argued against making the server guess, I
> > > presume this causes him some pain somehow (probably
> > underspecification
> > > in WSGI).
> >
> > Graham's issues with requiring the server to set Content-Length are
> > detailed here:
> >
> > http://blog.dscpl.com.au/2009/10/wsgi-issues-with-http-head-
> > requests.html
>
> Chris,
>
> Thanks for that link. I had completely forgotten about that issue. I'd
> really appreciate it if your web3 spec made some definitive decision on
> whether applications and middleware are responsible for correctly
> differentiating HEAD from GET, or whether servers should transform HEAD
> to GET before invoking the first application callable. I'd personally
> prefer the former.



Servers should definitely not transform a HEAD to a GET.

Transforming HEAD to GET and then discarding the body is often not a bad
default but an application may well want to handle the HEAD explicitly. For
instance, an application's HEAD handler may only need to check an ETag in a
database before returning a "304 Not Modified" response (with the correct
Content-Length and no body, of course).

Similarly, it's almost certainly a bad idea for a WSGI server or middleware
to change the Content-Length header in the application's HTTP response
because there may be no body to look at.

- Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20100920/8ab190c3/attachment.html>