Version: (using KDE 4.4.3) OS: Linux Installed from: Unlisted Binary Package gzip encoded files which are reported as encoding=gzip in the http headers are shown as encoded and unreadable. For example: https://edge.launchpad.net/ubuntu/+source/rekonq/0.4.0-0ubuntu1/+build/1558605/+files/buildlog_ubuntu-lucid-amd64.rekonq_0.4.0-0ubuntu1_FULLYBUILT.txt.gz
confirmed with latest git. btw: Arora shows the link fine
Also konqueror (webkit & khtml) has problems with this site. What I understood here is that: - file is a .txt.gz (so, a gzipped plain text) - "content-type" header is "text/plain; charset=utf-8" - "content-encoding" header is "gzip" This probably means: uncompress this file on the fly and then show it. But something goes wrong. All browsers tested (firefox, chrome, arora) seem behaving as expected here (directly show this file), but konqueror and rekonq. KIO issue?
So, it seems we can solve by ourselves. I just consider strange QNAM handles it on its own, while KIO does not.
status in the latest mainline with the link above is: when clicking the link, it loads for some seconds and then shows you the download dialog.
This still appears to be an issue. I have an apache clause that lets me browse gzip'ed plain text doc files in /usr/share/doc/, but rekonq tries to download them and open them in Ark, whereas firefox displays them natively. Is there a way to configure rekonq's mime types to decompress gzip'd text files on the fly? I'm running Ubuntu 11.04 server with KDE built on top.. The Apache config that deals with setting the content headers is:- <IfModule mod_mime.c> AddEncoding x-compress .Z AddEncoding x-gzip .gz .tgz AddEncoding x-bzip2 .bz2 AddType application/x-compress .Z AddType application/x-gzip .gz .tgz AddType application/x-bzip2 .bz2 </IfModule
EDIT: Apache needs this directive in the /usr/share/doc directory, for it to work:- <Directory "/usr/share/doc"> AddType text/plain .gz .tgz ... </Directory>
Dawit, any idea how we can solve this issue?
As usual the server side implementation is doing the wrong thing here by appending a ".gz" to the filename of a content that is a text file. Encoding a content for transport through the HTTP protocol does not mean you should actually change the filename of the content to reflect the encoding. That is if the .gz should not be appended to the filename. The fact that the server chose to append the ".gz" extension causes kio_http to internally convert the "Content-Type" sent by the server from "text/plain" to "application/x-gzip". Why ? Because there are a lot of other broken server side implementations out there that incorrectly send "text/plain" when they actually should have specified "application/x-gzip". To workaround that issue we havecode in kio_http that checks the filename extension whenever the content-type is "text/plain" and change the content-type as needed. The ".gz" extension happens to be one of those cases and hence this issue. I will see what can be done to fix this issue without causing other regression in kio_http.
Git commit 9e5eb77bd19bef0194fb89781a105fc87bd05fac by Dawit Alemayehu. Committed on 09/02/2012 at 18:16. Pushed by adawit into branch 'KDE/4.8'. Behave like all other browsers when a server responds with a gzip encoded content and appends the content's filename with ".gz". FIXED-IN: 4.8.1 M +1 -2 kioslave/http/http.cpp http://commits.kde.org/kdelibs/9e5eb77bd19bef0194fb89781a105fc87bd05fac
wow! Dawit, I have to ping you too much :D Thank you.
Git commit 93386f44cf4dbc95f264ee4e1e715a93d5644d01 by Dawit Alemayehu. Committed on 09/02/2012 at 18:16. Pushed by adawit into branch 'frameworks'. Behave like all other browsers when a server responds with a gzip encoded content and appends the content's filename with ".gz". FIXED-IN: 4.8.1 M +1 -2 kioslave/http/http.cpp http://commits.kde.org/kdelibs/93386f44cf4dbc95f264ee4e1e715a93d5644d01