W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2002

Re: Entities

From: Jeffrey Mogul <Jeff.Mogul@hp.com>
Date: Mon, 19 Aug 2002 16:16:49 -0400 (EDT)
Message-Id: <200208192016.g7JKGiho007437@wera.hpl.hp.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:19 GMT