New Editorial issue MESSAGE-BODY

Jim Gettys (jg@pa.dec.com)
Wed, 30 Jul 1997 04:47:48 -0700 

This is a multi-part message in MIME format, created by Pachyderm.
The parts are separated by "--1" lines.
The first part is a covering note, the others are attachments.

--1
Content-type: text/plain

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


--1
Content-type: message/rfc822

Received: by src-mail.pa.dec.com; id AA08111; Tue, 29 Jul 97 21:03:22 -0700
Received: by acetes.pa.dec.com; id AA10373; Tue, 29 Jul 97 21:03:21 -0700
Message-Id: <9707300403.AA10373@acetes.pa.dec.com>
To: jg
Cc: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>, mogul
Subject: Re: OPTIONS Spec 
In-Reply-To: Your message of "Tue, 29 Jul 97 20:02:05 PDT."             <9707300302.AA10980@pachyderm.pa.dec.com> 
Date: Tue, 29 Jul 97 21:03:21 MDT
From: Jeffrey Mogul <mogul>
X-UIDL: 670be86258a8f257b64bf91f49b2726a

	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.


--1--