[Web-SIG] PEP 444 (aka Web3)
matt.goodall at gmail.com
Mon Sep 20 18:31:23 CEST 2010
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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Web-SIG