DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14678>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14678 error in combination of SSL, keep-alive and chunked ------- Additional Comments From [EMAIL PROTECTED] 2003-02-27 22:35 ------- I have just encountered the same problem, and spent some time trying to figure it out. I have this setup: +--------+ +---------------+ +-------------------+ | client |--- HTTPS-->| apache 2.0.43 |---HTTP-->|Intranet Web Server| +--------+ +---------------+ +-------------------+ reverse proxy Sometimes (actually, every time after first request [Mozilla 1.2, HTTP 1.1, Keep-Alive on]) I'd see the headers instead of HTML content at top of the page, beginning with a zero, just like the original report. I installed ssldump and looked at traffic -- from proxy to client, _two_ end chunk trailers (zero, CRLF) were sent after the content. Then I used HTTP to connect to the proxy, and observed the same thing happen with ethereal. In this case, however, Mozilla parses responses correctly (who knows why). Excerpt from RFC 2616, section 3.6.1: "The chunked encoding is ended by any chunk whose size if zero, followed by the trailer, which is terminated by an empty line." In my case, the data sent was "0\r\n\r\n0\r\n\r\n". I think (if I decipher the RFC correctly) that the last chunk is "0\r\n" and the trailer is empty, and "\r\n" is the empty line. Thus, "0\r\n\r\n" is left in the client's IN pipe. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
