- From: Josh Cohen <joshco@microsoft.com>
- Date: Tue, 16 Dec 1997 14:59:57 -0800
- To: "'koen@win.tue.nl'" <koen@win.tue.nl>, mogul@pa.dec.com
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
why not make the spec say something like: ( the mode of http is to specify length whenever possible ) If there is no content length header and if the outermost TE is not chunked and the client/server doesnt understand that TE, it may respond 4XX unsupported transfer encoding.. Josh Cohen <joshco@microsoft.com> Program Manager - Internet Technologies > -----Original Message----- > From: koen@win.tue.nl [SMTP:koen@win.tue.nl] > Sent: Tuesday, December 16, 1997 4:26 AM > To: mogul@pa.dec.com > Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com > Subject: Re: What is Content-Length? > > Jeffrey Mogul: > > > > > If a message is sent on a persistent connection using > > > a transfer-coding that does not exactly preserve the > > > length of the data being encoding, then the "chunked" > > > transfer-coding MUST be used, and MUST be the last > > > transfer-coding applied. > > > > > > > Is there a reason to require that chunked be applied after a > > self-delimiting transfer encoding? There would be a (probably > > slight) performance penality for doing it and I don't see the > > purpose. > > > >It seems like a mistake to get into the business of specifying > >self-delimiting transfer codings (aside from chunked, which is > >a generic way to do that). > > I agree, but requiring chunked on top will get us in the much nastier > business of forbidding self-delimiting transfer codings specified by > others. > > It should be legal to use something like gzip as the top transfer > encoding. If a server has to put chunking on top of a gzipped stream > without knowing the size of the zipped data beforehand, this could be > quite expensive in terms of either memory copy operations or software > complexity. The same is true for decoding such a thing. > > >-Jeff > > Koen.
Received on Tuesday, 16 December 1997 15:04:11 UTC