W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1994

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

From: Fisher Mark <FisherM@is3.indy.tce.com>
Date: Fri, 02 Dec 94 05:50:00 PST
To: HTTP Working Group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Message-Id: <2EDF2801@MSMAIL.INDY.TCE.COM>

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:10 UTC