On 14.08.2006, at 12:00, Zoran Vasiljevic wrote:
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.
Hm... I was too fast, as usual. If I read Bernds email *carefully*, he says: <quote> In my test case, 'string length' on the parsed adp string gives me 7109 bytes, 'string bytelength' 7147 bytes, in the Header 'Content-Length' is 7147 and wget stops after byte 7109 (e.g. Opera requests the page twice, haha, I lost one day to figure out why): string length: 7109 bytes = bytes returned string bytelength: 7147 = Content-Length header </quote> This would mean that the Content-Length is actually defined as number of characters in the given content encoding and NOT number of bytes! This is of course something completely different.... Putting the streamin mode aside, the caller will usually know how many characters he's returning. He may not know how many bytes this will yield in the given encodong allright but this is not important then, as we will do this correctly during the send. So the "bug" you are reffering to is us setting the content-length on the basis of [string bytelength] instead on the basis of [string length] equivalent? If this is so, then the bug should be of course fixed and the "workaround" should be removed. That would leave us to turn on the chunked encoding ONLY when we serve streaming content. Do I see this right? Cheers Zoran
