Version: 0.0.1 (using KDE 4.6.0) OS: Linux When clicking a link to a file, for example a pdf or tgz file, konqueror does not know what to do with it without http content-type headers. So it asks what to do, without suggesting the default app for the mimetype. I think konqueror should use the local mimetype system, trying the filename and potentially even downloading a bit of the file for testing instead. Examples: Everytime I download a tarball from aur.archlinux.com, I have to type in "ark" in a dialog box, because of that, eventhoug the filename packagename.tgz should be recognizable. Reproducible: Always Steps to Reproduce: Go to http://aur.archlinux.org and try downloading a tarball for any package Actual Results: Konqueror does not know what to do, and asks my to select an application without suggestions Expected Results: konqueror would suggest to open with ark, or just open with ark if I asked it to always do that OS: Linux (i686) release 2.6.37-ARCH Compiler: gcc
I find only *.tar.gz or *.tar.bz2 files on http://aur.archlinux.org. When clicking a link to a file I get a dialog with Save as, Open with Ark, Open with and Cancel. That's what is configured in the file associations, so I can not reproduce with Kubuntu 10.10 (KDE 4.6.2)
I have the same issue with aur. They use some odd mimetype description maybe?
Another stupid server bug (and I am an ArchLinux user). It sends mime-type of "application/x-xz" instead of "application/x-xz-compressed-tar". If it sent the latter it would work correctly. I guess we have to workaround broken servers as usual.
Git commit 3332be75106b7d555e7a44a24875b0b5085821f1 by Dawit Alemayehu. Committed on 09/06/2011 at 09:57. Pushed by adawit into branch 'KDE/4.6'. Workaround yet another broken server that sends the incorrect mime-type information. This time it is the ArchLinux servers sending application/x-xz instead of application/x-xz-compressed-tar when downloading packages. BUG: 267345 FIXED-IN: 4.6.5 M +9 -0 kioslave/http/http.cpp http://commits.kde.org/kdelibs/3332be75106b7d555e7a44a24875b0b5085821f1
Git commit bf3064cb42f51370f343a61041ac28f7cf81e3d7 by Dawit Alemayehu. Committed on 09/06/2011 at 09:57. Pushed by adawit into branch 'master'. Workaround yet another broken server that sends the incorrect mime-type information. This time it is the ArchLinux servers sending application/x-xz instead of application/x-xz-compressed-tar when downloading packages. BUG: 267345 FIXED-IN: 4.6.5 (cherry picked from commit 3332be75106b7d555e7a44a24875b0b5085821f1) M +9 -0 kioslave/http/http.cpp http://commits.kde.org/kdelibs/bf3064cb42f51370f343a61041ac28f7cf81e3d7
please have a look at http://code.google.com/p/wkhtmltopdf/issues/detail?id=9 at the end of the page "committee.df" does not recognize the filetype using KDE 4.7 OpenSuSE
(In reply to comment #6) > please have a look at > http://code.google.com/p/wkhtmltopdf/issues/detail?id=9 > at the end of the page "committee.df" does not recognize the filetype > > using KDE 4.7 OpenSuSE There is nothing we can do about this. It is the server's fault. Here is how the server responds to our request: ============ Sending Header: GET /issues/attachment?aid=90032000&name=committee.pdf&token=ed08bbc57cc9b8bdd65216dec5292280 HTTP/1.1 Host: wkhtmltopdf.googlecode.com Connection: Keep-Alive User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.34 (KHTML, like Gecko) konqueror/4.7.40 Safari/534.34 Referer: http://code.google.com/p/wkhtmltopdf/issues/detail?id=9 Pragma: no-cache Cache-control: no-cache Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: gzip, deflate, x-gzip, x-deflate Accept-Charset: utf-8,*;q=0.5 Accept-Language: en-US,en;q=0.9 Keep Alive: true ============ Received Status Response: "HTTP/1.1 200 OK Cache-Control: max-age=31536000, public Last-Modified: Sun, 07 Aug 2011 17:59:19 GMT Expires: Mon, 06 Aug 2012 17:59:19 GMT content-disposition: attachment; filename="committee.pdf" Content-Type: application/octet-stream X-Content-Type-Options: nosniff Date: Sun, 07 Aug 2011 17:59:19 GMT Server: codesite Content-Length: 414243 X-XSS-Protection: 1; mode=block We cannot use the extension based workaround because the actual file name is sent through the content-disposition header.
@Dawit thanks for looking into this FYI - Firefox and Chrome propose the default app of the platform to open the file. So where is the magic?
(In reply to comment #8) > @Dawit > thanks for looking into this > FYI - Firefox and Chrome propose the default app of the platform to open the > file. So where is the magic? I guess the fix for this is at the brower engine level, i.e. kdewebkit and khtml. They need to consider the filename sent through the content-disposition header before poping up the open with dialog. Can you please do me a favor and open a new ticket against kdelibs/general for that specific issue ? We should not mix up different issues even when they seem related. That way it will be easier when searching for duplicates.
(In reply to comment #8) > @Dawit > thanks for looking into this > FYI - Firefox and Chrome propose the default app of the platform to open the > file. So where is the magic? @Ferdinand Please assign the ticket directly to me adawit at kde dot org. I already have a fix for this issue. :) Also open it against "Product: kdelibs" and "Component: kparts". Thanks.
new bug is here https://bugs.kde.org/show_bug.cgi?id=279675