Strange firefox behaviour GZIP + cache

[Scotty Sinclair]

Hi,

I am seeing some very strange behaviour in firefox 3.0.6.

I am returning content which is cached and gzipped (CSS/JS/HTML). The problem happens when I refresh the page when I have a cached version of the file. Firefox sends out a request to the server, the server responds with a 304 Not Modified and Firefox takes the version from the cache but it is corrupted. If I clear the cache then refresh will work for the next request, also if I don't gzip content then it will work too.

I have reproduced on HTTP, HTTPS, with and without a proxy configured

Looking at firebug there is no response header for the request and the content type is x-c, or application-x-unknown-content-type

Looking at httpfox, I can see a 200 response with a strange HTTP version (HTTP/0.9 200 OK) even though apache sends back a 304.

Looking at the cache entry using "about:cache", I can see that the real HTTP response headers are considered as part of the cached content itself. If I click on the URL link item to view the actual content source, then the source displays properly, and then when I refresh the cache entry the HTTP response headers are shown properly.

This makes me think it is a problem with firefox handling cached GZIPed content.

Has anyone seen this? or am I doing something stupid, since I would expect this to work. Please see my response headers for a javascript item below.

Date Tue, 03 Mar 2009 14:25:30 GMT
Server Apache/2.0.58 (Win32) mod_jk/1.2.19
Etag W/"5200-1235998716000"
Last-Modified Mon, 02 Mar 2009 12:58:36 GMT
Cache-Control max-age=2592000, public, must-revalidate, proxy-revalidate
Expires Thu, 02 Apr 2009 14:25:30 GMT
Vary User-Agent,Accept-Encoding
Content-Encoding gzip
Keep-Alive timeout=15, max=99
Connection Keep-Alive
Transfer-Encoding chunked
Content-Type text/javascript

[eveterinary]

I've Very same problem with my site. But the weird thing is it works perfectly on my local server (WAMP). Got anyone any idea why this thing happens, and only on firefox??? Opera No prob, Even on IE works OK.

Thanks

[Rev-Kev]

I'm having a very similar problem with gzip-ing css and js files. I've narrowed it down to a cause but not a fix.

It's not really a Firefox bug (though other browsers seem to handle it ok). And there is no HTTP/0.9 header being sent.

What is happening is that a line-feed character (x0A) is being inserted in front of the 1st header record (the HTTP/1.1 200 OK). This line-feed apparently causes Firefox to see everything after it as part of the content and thus sees no headers at all. Where you see an HTTP/0.9 being reported, it's an assumption on Firefox's part, it's not part of the data stream being sent from the server. You can see this in the about:cache screen.

Now, why or where that x0A is getting there, I have no idea. It may be the server (Apache), a firewall, or a proxy mucking with the data.

[Rev-Kev]

Don't know if anybody is still watching this (over a year) but I'll put it out there for the next fool searching for a cause/solution to this problem.

As I said, it's not really a bug in Firefox, and I don't think it's limited to gzip and it has nothing to do with HTTP/0.9 or with https/ssl (which, in my case was the only time it showed itself). It is related to keep-alive and a programming bug when capturing output and setting a content-length header.

Here's a simple erroneous example using PHP:

Code: Select all

1. <?php
2. ob_start();
3. // generate output
4. $buff = ob_get_clean();
5. $buff = gzencode($buff,6);
6. header('Content-Length: '.strlen($buff));
7. echo $buff;
8 ?>
9.

It's the blank line (line 9) at the end of the script that causes the problem (and almost every script ends this way). In the above example, if the generated output captured into $buff is 100 characters long, the Content-Length header is set to 100 and the 100 character $buff is outputted - followed by a single line-feed (line 9). This results in a 101 character output.

With Keep-Alive enabled, the 100 character output (designated by content-length) is consumed by Firefox leaving that single line-feed "on the wire" so to speak. The next request that is made over the same connection will first get that line-feed followed by the headers and content of what was actually requested. When Firefox sees that line feed, it assumes everything is content with no headers. (I assume other browsers simply ignore the leading line-feed).

The simple solution - eliminate line 9. However, the next programmer that comes along and inadvertently adds a line-feed at the end of the file reintroduces the problem (note that many text editors do this automatically).

A better solution (at least in PHP) is to use a registered shutdown routine to capture the output after completing the PHP script:

Code: Select all

1. <?php
2. register_shutdown_function('my_output');
3. ob_start();
4. // generate output
5. function my_output() {
6.     $buff = ob_get_clean();
7.     $buff = gzencode($buff,6);
8.     header('Content-Length: '.strlen($buff));
9.     echo $buff;
10. }
11 ?>
12.

In this case, the extra line-feed (now on line 12) is part of the output captured by ob_get_clean making the content of $buff 101 characters and the Content-Length header is set to 101.

[joychester]

Met similar problem with Firefox 3.6.3, IE works fine...
Apache access.log has indicated the .css file return 304 Not modified, however, FF seems neither receive 304 response code successfully nor retrieve it from local cache. So the page looks wired.
After disable Gzip on apache, the issue has gone...Looking forward to the final solution to this problem.

[PMPP]

Hi, I'm having a similar problem, in my case a gziped page (gziped with apache or with php, doesn't matter). Breaks the render of the page. And I'm talking only about pure HTML, no CSS at all. Firebug itself show's me the broken HTML, the view source shows everything fine. Putting <!-- comments to change the size of the file fixes it sometimes, breaks others.

Using FF 3.6.10 Win7 x64