On 20 September 2010 16:19, Robert Brewer <fuman...@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
_______________________________________________ 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
