263393 - File Compressed on Server Not Decompressed for Save Link Target As

Status: RESOLVED FIXED

(Core Graveyard :: File Handling, defect)

Description

[David E. Ross]

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

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.

Comment 2

[Boris Zbarsky [:bzbarsky]]

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

Comment 3

[Boris Zbarsky [:bzbarsky]]

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

Comment 4

[David E. Ross]

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

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

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