In working on the Options specification, Roy and Jeff came across a
problem in the spec that needed clearification.
For the record, here is the result.
- Jim
Forwarded message 1
Are you suggesting I incorporate your Options spec into draft 08?
No, this is a bug fix to a separate section, one that Roy discovered
while replying to something with this Subject. It is to replace
this sentence:
> A message-body MAY be included in a
> request only when the request method (section 5.1.1) allows an
> entity-body.
which you can probably find using a text-search.
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).
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!
Anyway, I think perhaps the best wording is:
A message-body MUST NOT be included in a request if the
specification of the request method does not allow
sending an entity-body in requests.
This means GET, HEAD, and DELETE, right?
-Jeff
P.S.: maybe I need some sleep, too.