Re: New Editorial issue MESSAGE-BODY

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:
>	GET /bar.html HTTP/1.1
>	Host:
>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