Bug 89999 - [test-case] Binary downloads are displayed without save dialog
Summary: [test-case] Binary downloads are displayed without save dialog
Status: RESOLVED FIXED
Alias: None
Product: konqueror
Classification: Applications
Component: khtml (show other bugs)
Version: 3.5
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-09-22 10:40 UTC by Andreas Mair
Modified: 2010-04-09 05:20 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Mair 2004-09-22 10:40:53 UTC
Version:            (using KDE KDE 3.3.0)
Installed from:    Gentoo Packages

Hi,

in our company we are using a virus scanning proxy that scans downloads for virusses. While this proxy is downloading and scanning it sends some HTML pages to the browser that refresh every 5secs. When it's done the browser receives a "File has been scanned for virusses" HTML page and the next refresh sends the requested download to the browser, which usually brings the "save" dialog. This works with Netscape/Mozilla, Opera, IE and used to work with Konqueror versions before KDE3.3.0. Now Konqueror displays the (binary) file in its window.

I think this has to do with some kind of MIME type caching, because the URLs that refresh are the same and have the same query values. I modified the virus scanning proxy to include a new query value when the next refresh will send the downloaded file to the browser. And voila: it works!

I hope I could make it clear...

Regars,
Andreas
Comment 1 Tommi Tervo 2005-08-03 15:59:50 UTC
dupe of this? http://bugs.kde.org/show_bug.cgi?id=81875
Comment 2 Andreas Mair 2005-08-04 10:11:08 UTC
No, I don't think so as the content type is submitted correctly. A binary file will usally not have text/html.
Comment 3 illogic-al 2007-01-06 16:01:37 UTC
NEEMOREINFO.
Is this bug still present? 
What is the mimetype of the file when sent to the browser? 
Comment 4 Andreas Mair 2007-01-08 10:43:54 UTC
Yes, it's still present (using KDE/Konqueror 3.5.5).
The mimetype is for example application/x-gzip when the file is sent to the browser.
I don't know how you can easily reproduce this bug, because refreshing works if the URL used for refreshing is different. But that's not true in my case.

Our virus scanning proxy works like this:
1) The browser requests a file that has to scanned for virusses, e.g. http://some.domain.de/binary_file.tgz
2) The VScanProxy downloads the file to a temporary file and runs a virus scanning tool on that file. Meanwhile it sends an HTML page to the browser telling the user that the requested file is scanned for virusses. This info page has the "refresh" meta tag so that the browser updates the info page and finally receives the virus free file. All info pages and the requested file have the same URL, only the mimetype is different.

If you need more info, please let me know!
Comment 5 Martin Fitzpatrick 2008-04-07 02:33:38 UTC
I've created a testcase here: http://www.mutube.com/x/kde/89999.php

If you open this page and repeatedly refresh it will increment the number (using cookies) until it reaches 10. At that point it will switch the mimetype to pdf.

On both KDE4.0.3/FF3 that triggers the opening of an external pdf viewer. According to this bug, that should not happen? Can someone confirm in 3.5.9 (also if original reporter could please confirm that the test case is valid, thanks).
Comment 6 Andreas Mair 2008-04-10 15:00:19 UTC
Your example works fine using konqueror 3.5.8.
The only difference I can see to my original report is that the virus scanning proxy include some meta tags:
<html>
<head>
<meta http-equiv="Expires" content="Thu, 01 Jan 1970 00:00:00 GMT">
<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="Cache-Control" content="private">
<meta http-equiv="refresh" content="5; URL=http://www.domain.org?some=query&filename=filename.ext">
</head>...

This header is sent to the browser as long as the file is downloaded and scanned for virusses. The HTTP header has "Content-type: text/html" set. When downloading and scanning is done and the browser refreshes the page again the downloaded file is sent to the browser, having the original content type in the HTTP header (e.g. "Content-type: application/octet-stream").
Comment 7 George Goldberg 2008-05-06 09:33:55 UTC
Martin, can you possibly update the testcase re: comment #6
Comment 8 Martin Fitzpatrick 2008-05-06 16:20:57 UTC
Thanks for the additional information Andreas (& for the prompt George). An updated testcase is available here: http://www.mutube.com/x/kde/89999.php

Confirming the bug still exists on KDE4.0.3.

Open the testcase and it'll now refresh automatically every 5 seconds. On the 3rd refresh it will change the content type to pdf. 

Firefox opens a pdf viewer, Konqueror does not (you will see "This should be a pdf file." displayed as plain text). Interestingly if you refresh manually, it *will* open the pdf viewer: which explains why the original test case didn't catch this.
Comment 9 Andreas Mair 2008-05-07 09:19:32 UTC
I can also confirm that the new testcase is valid.
Konqueror 3.5.8 shows the plain text and Firefox 2.0.0.14 opens the PDF viewer.
Comment 10 Jaime Torres 2008-06-29 13:46:20 UTC
Confirmed the bug in 3.5.9 and konqueror 4.1b2 svn trunk 824530.
Comment 11 Raphael Kubo da Costa 2010-04-09 04:23:07 UTC
I was unable to reproduce this bug -- after the counter reached 3, Konqueror showed a download dialog asking if I wanted to download the PDF file. Subsequent reloads would load an Okularpart in Konqueror.

Maybe this has been fixed?
Comment 12 Martin Fitzpatrick 2010-04-09 04:36:33 UTC
Looks that way to me. 

Although the downloading the first time/then Okularpart in Konqueror is also a bug is it not? Shouldn't it continue to do whatever it is supposed to do the first time?
Comment 13 Raphael Kubo da Costa 2010-04-09 04:44:50 UTC
Yup, but I think that's a different bug, but I'm too lazy to file a new report right now :(
Comment 14 Raphael Kubo da Costa 2010-04-09 05:19:16 UTC
Actually, I'm not sure it's really a bug -- it can be seen as Konqueror being too picky.

KonqMainWindow::openView checks whether the request is a user-requested reload, or if the user typed the given URL himself. In both cases, it forces embedding.
Comment 15 Raphael Kubo da Costa 2010-04-09 05:20:13 UTC
Closing as the original bug has already been fixed.