On 13.08.2006, at 20:03, Michael Lex wrote:


This chunked-transfer-encoding thing is only a workaround until the
Content-Length bug is fixed.

I've been reading various posts from you, Bernd, Vlad and Stephen
about that...

I must say: the problem is that the *correct* content-length
header is/would-be difficult (or costly in terms of memory
and time) to compute for  dynamic content.

The way how the things are handled now, the caller passes the
equivalent to [string length] bytes and an encoding to the
underlying routine(s). They encode the content *on-the-fly* so
the caller cannot possibly know in advance what to put in the
Content-Length header as the *real* output length may/will
change depending on the selected encoding.

After all, the chunked encoding IS defined exactly for
this reason: to allow the recepient to verify the number
of bytes received, when it is impossible or not feasible for
the generator to specify exact number of bytes sent.

If you looking it from that perspective, the "workaround" Bernd
has made is actually pretty much OK.

I wonder how you can set a correct Content-Length if you use
ADP streaming...

The above case (using explicit output encoding) is (admitently)
not exactly the same as streaming, as you COULD encode the string
before sending and then set the correct content-length, but this
would mean memory bloat as you will have to transform the entire
content beforehand...

Therefore, if you ask me, the "workaround" should be left there.

Another thing... I guess if we do not return the Content-Length
at all, and we do not use chunked transfer encoding, the browser
will slurp everything until EOF, right? But this can only be done
for non-keepalive connections... Hm... Wrong turn....

If you ask me, I think we must make sure our test routines also
know how to decode chunked encodings and we should leave the
"workaround" in place. If we all agree that this is the way to go
we can check other places in the code and make sure they do the
same: if output encoding set, turn-on the chunked transfer encoding.

What do others think?

Cheers
Zoran



Reply via email to