Re: What is Content-Length?

On Thu, 11 Dec 1997, David W. Morris wrote:

> 
> 
> On Thu, 11 Dec 1997, John Franks wrote:
> 
> > I would prefer Content-length to be the length BEFORE any transfer
> > encoding.  From Scott's remarks it is clear this is what he
> > understands content length to be.  But if Content-length is length
> > before transfer encoding we must introduce a Transfer-length header or
> > forbid any future transfer encodings which are not self-delimiting.
> 
> As I've already said, transfer encoding was introduced to resolve the
> problem that some servers don't know the total length until 
> the whole document has been sent.  

That was the reason "chunked" was introduced.  There are other reasons
one might want to use a Transfer-encoding, e.g. compression to conserve
bandwidth.

> All future transfer encodings MUST
> be self-delimiting. 

What is the basis of this assertion?

I find no evidence this was the intent of the protocol authors.

> It would be stupid to introduce a new header
> whose value can't always be computed to define the length of 
> some possible new method of encoding.
> 

Or it might be stupid to preclude the possibility of ever using 
lots of useful transfer encodings to avoid introducing a new
header.

Here's one scenario that I think people have in mind.  A proxy
receives documents, compresses them on the fly and caches the
compressed version (saving disk space).  When a client requests the
document it is served in the compressed form (with the appropriate
Transfer-encoding header) to save bandwidth.  The proxy knows
the compressed length; the client needs to know it for the transaction
to work.

John Franks
john@math.nwu.edu