- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Mon, 15 Jan 2007 14:50:44 -0800
- To: Scott Lawrence <scott@skrb.org>
- Cc: Mark Nottingham <mnot@mnot.net>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.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. ....Roy
Received on Monday, 15 January 2007 22:50:41 UTC