- 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
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. > >or > > 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. ....Roy
Received on Saturday, 9 August 1997 02:10:54 UTC