Regarding to the preceding discussion on the mailinglist, now the bugreport. As Rasmus Lerdorf said, the problem occurs only if the response is keep-alive and chunked and the server delivers per https. So my suggestion is, that there somewhere a problem with mod_ssl, keep-alive and/or chunked content. You can see it in my little 'test-suite': HTTP-Version: http://xmail.linux-de.org/test/ HTTPS-Version: https://mail.linux-de.org/test/ The ssl-version produces some very strange output... most of the time this is happening with php. Then you get an header beginning with: ----start---- 0 HTTP/1.1 200 OK Date: Mon, 11 Nov 2002 11:31:32 GMT Server: Apache/2.0.43 (Unix) mod_ssl/2.0.43 OpenSSL/0.9.6g ----snip----- and some random characters in the document.
FYI: I've tried setting 'KeepAlive Off' and the problem was solved, so the problem has to do with that.
looks like ssl output filter may be sticking the bucket containing the ending chunk in the wrong place I assume that disabling keepalive caused Apache to use connection close instead of chunking, which avoided the other problem.
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.
This looks like a duplicate of bug 14451 (see comments to this change for details: http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/util_filter.c.diff?r1=1.93.2.1&r2=1.93.2.2&only_with_tag=APACHE_2_0_BRANCH) I put this file into my 2.0.43 tree and voila! that fixed it.
Thanks for tracking that down. *** This bug has been marked as a duplicate of 14451 ***
*** Bug 19429 has been marked as a duplicate of this bug. ***
Reopening a bug that is closed that long without any new information does not make any sense. *** This bug has been marked as a duplicate of 14451 ***
I have just encountered a similar problem. I have this setup: +--------+ +---------------+ +-------------------+ | client |--- HTTPS-->| apache 2.0.59 |---HTTP-->| JBoss App Server | +--------+ +---------------+ +-------------------+ (Firefox) (mod_ssl + mod_jk) When browser invokes GET Method on resources provided by the application server (dynamic javascript in our case), the received response is as expected "HTTP/1.1 200 OK" with the correct body. Following GETs on the same resource produce 304 status code. Reproducibly often but not always the response contains some data. For some reason this gets interpretted as a 200 (as shown by the headers) and the browser displays in error console the following lines (it's a javascript resource) : Error: missing ; before statement Source File: ...<uri of the resource>... Line: 4, Column: 9 Source Code: HTTP/1.1 304 Not Modified As reported in "https://bugzilla.mozilla.org/show_bug.cgi?id=364556" this seems due to some additional characters into body (something like "0\r\n\r\n0\r\n\r\n" ?). Using Firefox, the loaded resources and browser memory cache are corrupted. Ie6+ seems not to suffer the same problem, it seems to ignore the body when the return status is 304. Unfortunately this problem occurs on daily basis on our servers, thus limiting the use of our https services for firefox browser.
sorry for empty post: an hasty click. I know This bug has been marked as a duplicate of 14451, but even if that bug results fixed in 2.0.45, I still have the problem in 2.0.59, and as described in my previous post it seems more similar to this "14678" than to "14451".
More information. Verborse log of mod_jk shows that response interpreted as corrected by browser and corrupted one have the same dump at mod_jk level.
More information. Setting KeepAlive=Off fix the problem. It may be that "Apache" dirty some buffer when it reuses the same connection. Putting the following line: BrowserMatch Firefox nokeepalive "Internet Explorer" works as before and firefox does not use keepalive connections.
Changing back to fixed. If JBoss is including a response body with some 304 responses, it's in violation of the HTTP standard (RFC 2616) and needs to be fixed. Not Apache's problem.