W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 1998

Re: Has the Content-Length issue been resolved?

From: Life is hard... and then you die. <Ronald.Tschalaer@psi.ch>
Date: Mon, 19 Jan 1998 08:45:50 +0200
Message-Id: <98011908455057@psiclb.psi.ch>
To: HTTP-WG@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/5217

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
Received on Sunday, 18 January 1998 23:53:12 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:04 UTC