Firefox appears to decompress gzipped databased exported via phpMyAdmin




File Handling
10 years ago
10 years ago


(Reporter: Kris Kelly, Unassigned)


Firefox Tracking Flags

(Not tracked)




10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv: Gecko/2008092417 Firefox/3.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv: Gecko/2008092417 Firefox/3.0.3

If I download a gzipped database export via phpMyAdmin 2.11.5 (it also occurs in version in FF3.0.3 (happened in earlier versions too), it is retrieved as an uncompressed SQL file with the .gz extension.  The SQL is often truncated (especially noticeable on databases over 2MB in size).

Reproducible: Always

Steps to Reproduce:
1. Use firefox 3 to export a gzip compressed database in phpMyAdmin 
2. View it in a text editor
Actual Results:  
The file is no longer a gzip compressed file, but a plain text file.

Expected Results:  
It should be gzipped

I can successfully download files in Opera and decompress them so it's not phpMyAdmin.

I suspect this is a result of firefox interpreting the file as being content that should be decompressed and then displayed (as a css or image file would be when sent from apache with the deflate option enabled).

This *might* explain the truncated SQL, since the server may report it as being a 1.5MB gzip file and firefox may interpret that as here's a file that is gzipped, it's original size is 1.5MB and so decompresses only 1.5MB of a possible 7MB SQL.
What are the headers for this file from the server ?

Comment 2

10 years ago

POST /phpmyadmin/export.php HTTP/1.1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv: Gecko/2008092417 Firefox/3.0.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: pmaCookieVer=4; pma_lang=en-utf-8; pma_charset=iso-8859-1; pma_collation_connection=utf8_unicode_ci; pma_navi_width=200; pma_db_filename_template=__DB__; phpMyAdmin=987fe30fe1d2e70a103c0ccd4540f7b4
Content-Type: application/x-www-form-urlencoded
Content-Length: 1380
HTTP/1.x 200 OK
Date: Sat, 01 Nov 2008 18:11:13 GMT
Server: Apache/2.2.6 (Win32) DAV/2 mod_ssl/2.2.6 OpenSSL/0.9.8e mod_autoindex_color PHP/5.2.4
X-Powered-By: PHP/5.2.4
Set-Cookie: pma_fontsize=82%25; expires=Mon, 01-Dec-2008 18:11:13 GMT; path=/phpmyadmin/; httponly
Set-Cookie: pma_theme=original; expires=Mon, 01-Dec-2008 18:11:13 GMT; path=/phpmyadmin/; httponly
Expires: Sat, 01 Nov 2008 18:11:13 GMT
Cache-Control: private, max-age=10800, pre-check=10800
Last-Modified: Thu, 20 Sep 2007 16:35:14 GMT
Content-Encoding: x-gzip
content-disposition: attachment; filename="p_info.sql.gz"
Pragma: no-cache
Content-Length: 479
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: application/x-gzip
The server sends:
Content-Encoding: x-gzip

Does the server encode the .gz file with gz (double gz encoded) ?
If it just sends the gz file without encoding it again then it shouldn't set the header. :
The Content-Encoding entity-header field is used as a modifier to the media-type. When present, its value indicates what additional content codings have been applied to the entity-body, and thus what decoding mechanisms must be applied in order to obtain the media-type referenced by the Content-Type header field.
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 424306
You need to log in before you can comment on or make changes to this bug.