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

Mike Cowlishaw writes in <9412011958.AA00957@hplb.hpl.hp.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?

Content-Length will only be essentially present when PUT and POST deal with 
pre-existing forms and files.  Doing a PUT or POST with large amounts of 
data created on-the-fly does not lend itself well to use of Content-Length 
as documented better by others than myself on this list.  I really hate to 
restrict the possibilities for future Web applications by making the 
multi-part stuff optional (or leaving it out entirely).

What is so particularly gawky about the multi-part stuff?  From my 
viewpoint, you either have to deal with fragmentation (UDP) or with message 
boundaries (TCP with multi-part messages).  If you have a better idea on 
handling multiple bodies of data, I for one would sure like to hear it.
======================================================================
Mark Fisher                            Thomson Consumer Electronics
fisherm@indy.tce.com           Indianapolis, IN

"Just as you should not underestimate the bandwidth of a station wagon
traveling 65 mph filled with 8mm tapes, you should not overestimate
the bandwidth of FTP by mail."

Received on Friday, 2 December 1994 04:00:14 UTC