Zoran Vasiljevic schrieb:
On the fly I mean that the message is not encoded in its *entirety*
beforehand, rather it is converted piece-by-piece (hence on-the-fly)
in Ns_ConnWriteVChars().
there are not much options, when the output encoding changes length.
So, what do we have now?
A. For HTTP 1.0 clients only, we could/should/must either:
a. omit content-length and turn keepalive off leaving
the browser to drain the connection until EOF.
HTTP/1.0 does not say anything about keepalive
(http://www.ietf.org/rfc/rfc1945.txt)
but sending a "connection: close" does not hurt, since some nonstandard
clients
use it.
b. calculate the content-length in advance by
performing the conversion of the message
in its entirety in the memory using the given
output encoding
the calculation is only needed in cases, where the output is not raw
(e.g. delivering
images, i would not call it UTF8 encoded (see below), rather "raw")
B. For HTTP 1.1 clients we can turn on chunked encoding
if the output encoding is specified, and is not UTF8
(basically, this is what Bernd's workaround does).
... or there is for some other reasons no translation going on (see above)
Without looking into the code, i would assume that the simplest case
would be to distinguish between cases, where the content-length is
unknown and known.
unknown means: transformation or dynamic content.
for unknown cases i would omit in HTTP/1.0 the content-length and use
in HTTP/1.1 the chunked encoding
the known-case is a non-brainer.
-gustaf
