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

Re: New Editorial issue MESSAGE-BODY

From: Roy T. Fielding <fielding@kiwi.ics.uci.edu>
Date: Sat, 09 Aug 1997 01:47:04 -0700
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <9708090206.aa07864@paris.ics.uci.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4124
Jeff wrote:
>Roy suggests:
>     A message-body SHOULD NOT be included in a request unless the
>     request method is defined as allowing an entity-body.
>     A server SHOULD read and forward a message-body on any request;
>     if the request method does not include defined semantics for an
>     entity-body, then the message-body SHOULD be ignored when handling
>     the request.
>I'm not sure why we shouldn't just say both things (robustness
>principle: don't send garbage, but don't choke on it, either).

Including both is fine with me.

>Actually, on reflection, I'm not sure how I would implement
>a server that can figure out that a GET without a content-length,
>but which has a bogus body, isn't actually two GETs.  I.e.,
>if a bad client sends
>	GET /foo.html HTTP/1.1
>	Host: foo.com
>	GET /bar.html HTTP/1.1
>	Host: foo.com
>is that (1) two GETs on a persistent connection, or (2) one
>GET with a bogus body and no Content-length?  Or do the
>rules for persistent connections not allow this? I skimmed
>RFC2068, and I don't think we require this!

A request message body is indicated by the presence of Content-Length
or Transfer-Encoding, as described in section 4.2 (Message Body).
Granted, it doesn't say MUST, but it is easy to implement.

Received on Saturday, 9 August 1997 02:10:54 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:03 UTC