RE: What is Content-Length?
Josh Cohen (joshco@microsoft.com)
Tue, 16 Dec 1997 14:59:57 -0800
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.