W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2007

Re: i19 Bodies on GET (and other) requests

From: Roy T. Fielding <fielding@gbiv.com>
Date: Mon, 15 Jan 2007 14:50:44 -0800
Message-Id: <366448C2-DCF0-4988-9F37-9B67728A1135@gbiv.com>
Cc: Mark Nottingham <mnot@mnot.net>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
To: Scott Lawrence <scott@skrb.org>

On Jan 15, 2007, at 5:34 AM, Scott Lawrence wrote:
> On Mon, 2007-01-15 at 17:35 +1100, Mark Nottingham wrote:
>> Background at:
>> <http://lists.w3.org/Archives/Public/ietf-http-wg/2006AprJun/0103>
>> Does anybody have any new information / thoughts about this?
> It seems to me that inferring anything about the presence or  
> absence of
> a body based on the method only creates ambiguous situations when that
> inference is in conflict with the explicit indications already defined
> by the protocol (the Content* and Transfer* headers).

Right, it would just create contradictions where none are necessary.

> The only exception to this should be HEAD.  In retrospect, I think  
> that
> HEAD should have defined special headers to express what would have  
> been
> in the body descriptors so that there was no ambiguity
> (head-content-length would have the value that would have been in
> content-length if the method had been GET, etc).

Heh, we realized way back in 1994 that HEAD should have been defined
to return a body containing the GET-headers, but even back then it was
way too late to fix that weirdness.  At the time, content-length was
just advisory (for the progress bar) anyway, so it was actually a
significant change to the message semantics to enable persistent
connections work at all over HTTP/1.x.

It is absolutely critical that the algorithm for determining the
presence or absence of a body have no dependence whatsoever on the
semantics of the method (aside from HEAD).  Failure to sustain that
design would mean that all proxies must block all new methods.

Received on Monday, 15 January 2007 22:50:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:41 UTC