Re: Has the Content-Length issue been resolved?

On Thu, 15 Jan 1998, John Franks wrote:
> 
> Has the Content-Length issue be resolved?  I.e. is the Content-Length
> value the length before or after a Transfer-encoding is supplied?

I don't believe so, and I for one would be glad to get it decided. As I
see it there are basically four solutions to this problem:

1) Content-Length is the length after t-e.

2) Add a new header Transfer-Length for t-e's other than chunked and
   identity.

3) Require all t-e's to be self delimiting.

3a) If a t-e is not self delimiting then either use a Transfer-length,
    Content-length or chunked t-e on top

4) require the "outermost" t-e to be the chunked t-e

I think that 1) is bad and unnecessary. Content-length has never been
the length after t-e is applied, as previously the only t-e's were
identity and chunked (Content-length was ignored when the chunked t-e
was used). Let's leave Content-* as applying to the entity before
t-e.

I also don't like 3) and 3a) for implementation reasons: in a client
the partitioning of the input stream into responses is a very low level
operation. If self delimiting t-e's are allowed then supporting a new
t-e would require changes to the core code, making it harder to write
extensible clients. I'd rather see the number of ways the body can be
delimited frozen once and for all (the currently 4 ways are quite
enough, IMHO). Also, this solution means clients can't just use
existing decompression libraries (such zlib) to decode the body;
instead they have to implement at least parts of the code themselves.
And lastly, this solution would prevent the existence of clients which
accept all t-e's, possibly storing the response for later processing by
some other software (such as spiders and similar clients).

This leaves 2) and 4). The disadvantage of 4) is that it might use a few
bytes more than 2). Furthermore, some people have expressed concern that
4) would require extra copying of the data on the server side, but I'm
not sure how true this is if implemented correctly. On the other hand I
personally like 4) because it requires the least changes to client code,
but I can live with either solution. Note that if t-e's are going to be
computed on the fly then servers will have to resort to chunking anyway.

Just my 2 Rp.


  Cheers,

  Ronald