- From: Jeffrey Mogul <Jeff.Mogul@hp.com>
- Date: Mon, 19 Aug 2002 16:16:49 -0400 (EDT)
- To: "Larry Masinter" <LMM@acm.org>
- cc: "'Alex Rousskov'" <rousskov@measurement-factory.com>, "'Kim Horne'" <kim@pookzilla.com>, <ietf-http-wg@w3.org>
Larry Masinter writes:
I believe (and I think the email record supports) that the
assumption has been that GET, HEAD and DELETE don't have
entity bodies and thus senders MUST NOT send one,
even though proxies and servers SHOULD read, forward
and (when processing) ignore one if they get one.
I also think this is the safest interpretation; certainly
it wouldn't be possible to add any semantics to entity
bodies for GET or HEAD, since proxies and other kinds of
intermediaries would discard them.
I'm tempted to call this an errata: we intended to write the
specification more clearly but failed to do so. However,
given the noise around 'GET with body', I suppose we
might need to treat this as an issue.
The main point of forbidding body with GET is the belief
that it would fail with large chunks of deployed infrastructure;
servers that would crash or give erroneous results if
presented with a GET with a body. I haven't seen any
reports, although I remember some speculation about this.
Here's a little thought experiment: Can we construct an example
request that is ambiguous if the server DOES accept a body for
a GET?
For example,
<open TCP connection>
GET /foo.html HTTP/1.1
Host: example.com
GET /bar.html HTTP/1.1
Host: example.com
Connection: close
<close TCP connection>
Is this example:
(a) a pipelined connection with two GETs for distinction URLs?
(b) a single GET whose "body" looks a lot like the headers for
another GET, but is actually just a BODY.
Probably if the example had included an explicit Content-length
field in the first group of headers, the ambiguity would go
away, but I think the Message Length rules (section 4.4) don't
require that.
My vote: treat this as an erratum; ban bodies for GET, HEAD, and
DELETE.
-Jeff
Received on Monday, 19 August 2002 16:49:36 UTC