views:

23

answers:

2

Standard scenario: ajax-heavy web application with reports that can be downloaded as files.

Problem: Internet explorer blocks file downloads with its yellow "security bar". When you click on the bar and allow to download, the whole page gets refreshed and data entered is lost.

Question: what counts as a blockable download? Does it look at the Content-disposition: attachment header? Does it deny downloads from POST requests? Is there any scenario at all in which it simply opens the download box without the yellow bar?

A: 

Microsoft's definition is:

Internet Explorer will block a file from downloading if it appears that you did not request the file. This might happen if a website tries to download files to your computer without your permission or if you requested a file but the download did not start immediately.

I thought I'd assist you with an example for the case, and my conclusion from it and Microsoft's definition, but I can't find a solid connection. Check the request's "Accept" against the response's "Content-type", maybe they contradict.

Hila's Master
+1  A: 

This has nothing to do with the file type and everything to do with what user-action preceded it. If a "User-initiated action" is detected as the immediate cause of the download (e.g. the user clicked on a link directly to the download, or pushed a button, etc) then the download dialog is presented instead of the Information Bar.

The #1 problem is sites that use the user's click to navigate to some other page (e.g. thanks for downloading "foo") and have that page try to launch a file download. Because the User-Initiated flag is lost as a result of the navigation, the Information Bar blocks the download.

Some background: XPSP2 introduced a File Download blocker to combat malicious sites that would spam the user with download prompts for malware as the site loaded. Criminals hoped that the user might inadvertently accept a malicious download. After the File Download blocker was added, a page that attempts to perform a download without a preceding UIA will result in an Information Bar being shown:

While it is trivial for a legitimate site to avoid this Information Bar (simply launch a single download as a direct result of a UIA) most legitimate sites don’t bother to do this. For instance, a site whose primary purpose is to download files has the greatest incentive to make doing so a pleasant user-experience, but downloading from Download.com still triggers this Information Bar six years after the blocker was introduced. Even the new IETestDrive.com site shows this Information Bar when a user attempts to install the IE9 Platform Preview Builds, because the site navigates to a new page (rather than immediately triggering a download) when the user clicks the “Install Preview” link.

EricLaw -MSFT-
In my case I generate the URL from Javascript based on user choices selected in the form. Then I generate a form and submit it. All this is done in an `onclick` handler, but the bar still triggers. :(
Vilx-
I have to use a POST form because there also is one rather large field with some serialized state. About 10KB. It wouldn't fit in an URL.
Vilx-
No, wait... in some cases there is still an AJAX request before I submit the form, so the submitting isn't a user-initiated action. Damn...
Vilx-