Re: Comments on HTTP draft [of 23 Nov 1994]
Fisher Mark (FisherM@is3.indy.tce.com)
Fri, 02 Dec 94 05:50:00 PST
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."