Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.3) Gecko/20040910 If I open a compressed file in a Mozilla browser window, it looks fine. Mozilla has properly decompressed it. If I then request "Save Page As" on the context menu, the result is also okay. However, if I select a link to that file and request "Save Link Target As" on the context menu, I get binary garbage. I can neither edit the file nor display it via the Mozilla browser. Steps to Reproduce: 1. Go to the indicated URL. 2. Place cursor over "My Blog" link. 3. Right-click. 4. On context menu, select "Save Link Target As". 5. Save the file, using the default file-type (HTML). 6. Attempt to open the saved file via Mozilla. 7. Attempt to view the file via an ASCII file editor. Actual Results: Garbage (step 6 above caused Norton Anti-Virus to issue a spurious virus warning). Expected Results: Saved file should be viewable by Mozilla. When viewed with an ASCII file editor, XHTML source should be seen. Note: The fact that the blog is the same as the home page makes no difference in this bug.

This is a bug in the server, actually. The HEAD response looks like: HTTP/1.1 200 OK Date: Thu, 07 Oct 2004 23:22:15 GMT Server: Apache/1.3.31 (Debian GNU/Linux) mod_gzip/1.3.26.1a mod_perl/1.29 Cache-Control: max-age=300 Expires: Thu, 07 Oct 2004 23:27:15 GMT Last-Modified: Fri, 30 Jul 2004 11:53:24 GMT ETag: "36ce7-4986-410a36b4" Accept-Ranges: bytes Content-Length: 18822 Content-Type: text/html; charset=iso-8859-1 while the GET response looks like: HTTP/1.1 200 OK Date: Thu, 07 Oct 2004 23:23:11 GMT Server: Apache/1.3.31 (Debian GNU/Linux) mod_gzip/1.3.26.1a mod_perl/1.29 Vary: Accept-Encoding Cache-Control: max-age=300 Expires: Thu, 07 Oct 2004 23:28:11 GMT Last-Modified: Fri, 30 Jul 2004 11:53:24 GMT ETag: "36ce7-4986-410a36b4" Accept-Ranges: bytes Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html; charset=iso-8859-1 Content-Encoding: gzip Content-Length: 3847 in response to the same request header. Note the difference in Content-Length and Content-Encoding headers. So as far as we can tell, when we do the HEAD, the page is NOT compressed. This will probably be fixed by us stopping the use of HEAD altogether (because of servers like this one), but I would strongly suggest fixing the server as well.

This should be fixed in a current build. Please retest.

Fixed, per mail from reporter (by checkin for bug 160454).

Although I verified that this is fixed for 1.8a5, I have also verified that this is NOT fixed for 1.7.5. Apparently, the 1.8 fix did not migrate to the trunk. Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.5) Gecko/20041217

eh? 1.8a5 is trunk (or was, when it was released). 1.7.5 is a branch, using comparatively old code.