Re: Comments on HTTP draft [of 23 Nov 1994]

Mike Cowlishaw writes:

> [aside] Odd: the version I have proclaims itself "This document is an
>         Internet-Draft".  Problems with document control somewhere!
>         How will the Real Internet-Draft be identified?

That was a draft of an Internet Draft. ;-)
The real I-D has the filename <draft-fielding-http-spec-00.ps>
in the upper-left corner of the first page.
Sorry again for the confusion.

>> It goes something like this:
>>
>>   a) If message includes Content-Length, use it.
>>
>>   b) If message uses an as-yet-undefined packetized Content-Transfer-Encoding
>>      then that encoding may define an EOF marker.
>>
>>   c) If message uses an as-yet-undefined packetized Content-Encoding,
>>      then that encoding may define an EOF marker.
>>
>>   d) If message is of type multipart/*, the effective object body ends
>>      when the boundary close-delimiter is reached.
>>
>>   e) If the connection closes, the object body has ended.
>>
>> Part (b) is along the lines of Dan Connolly's www-talk proposal of
>> 27 Sep 1994 (Message-Id: <9409271503.AA27488@austin2.hal.com>).
> 
> I'm happy with the situation for responses (connection closes is quite
> good enough), but still very unhappy with this definition for the data
> (object body) for requests (PUT and POST).  The steps you just
> outlined are not defined sufficiently well to be implementable (and
> requiring every server to implement the rather gawky multi-part stuff
> just in case data comes in that way seems unnecessary).  Is not
> Content-Length essentially always present, in current practice, for
> PUT and POST?  In which case, why require more that this, or
> alternatives, unless truly necessary?

The intention is to move away from "connection closes is quite good enough"
so that future versions of HTTP can support a connection keep-alive.
Multipart types have always been possible to implement -- its just that
server and client authors have neglected (in the past) to read the MIME
spec and thus understand that these things exist and how they are implemented.
Including these descriptions in the spec is a way to prod people into
implementing something that should have been supported long ago.

Whether they stay in the spec, get moved to an appendix, or get shoved
off to HTTP/1.1 is a question for the group to decide.


......Roy Fielding   ICS Grad Student, University of California, Irvine  USA
                                     <fielding@ics.uci.edu>
                     <URL:http://www.ics.uci.edu/dir/grad/Software/fielding>

Received on Thursday, 1 December 1994 18:50:01 UTC