Bug 267345 - Konqueror does not recognize remote files from extension
Summary: Konqueror does not recognize remote files from extension
Status: RESOLVED FIXED
Alias: None
Product: konqueror
Classification: Unclassified
Component: general (show other bugs)
Version: 0.0.1
Platform: Archlinux Packages Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-28 23:16 UTC by Anders Lund
Modified: 2011-08-08 17:52 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.6.5


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Anders Lund 2011-02-28 23:16:21 UTC
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
Comment 1 Burkhard Lück 2011-05-20 15:41:08 UTC
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)
Comment 2 Anders Lund 2011-05-20 17:42:28 UTC
I have the same issue with aur. They use some odd mimetype description maybe?
Comment 3 Dawit Alemayehu 2011-06-09 09:57:29 UTC
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.
Comment 4 Dawit Alemayehu 2011-06-09 10:03:03 UTC
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
Comment 5 Dawit Alemayehu 2011-06-09 10:03:36 UTC
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
Comment 6 Ferdinand Gassauer 2011-08-07 09:43:43 UTC
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
Comment 7 Dawit Alemayehu 2011-08-07 18:12:51 UTC
(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.
Comment 8 Ferdinand Gassauer 2011-08-08 07:33:46 UTC
@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?
Comment 9 Dawit Alemayehu 2011-08-08 13:56:40 UTC
(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.
Comment 10 Dawit Alemayehu 2011-08-08 17:39:02 UTC
(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.
Comment 11 Ferdinand Gassauer 2011-08-08 17:52:02 UTC
new bug is here
https://bugs.kde.org/show_bug.cgi?id=279675