Problem saving a file with the "Content-Disposition" HTTP Response header field.

Question

First, some background information on the environment.  We have an industrial device that has a mini-webserver installed.  The Ethernet connection is point-to-point.  The device also has mini dhcp and dns servers.  When it receives a DHCP request, the PC is given a unique IP address on a private network, and a DNS request for "atb.qpm" responds with the device's IP address.  It remains quiet for all other DNS requests.

This device saves parameter information in a JSON file.  It uses this file like a multi-level INI file.  Using Internet Explorer 8, I am requesting the following URL:

http://atb.qpm/system/spindle1/controller/data/params.json?download=jobs.json&sections=jobs,psets

This URL is really a CGI-type request. The left part is the file name to look at, "/spindle1/controller/data/params.json".  This argument means returns the two sections "jobs" and "psets" as if it were an independent file: "sections=jobs,psets".  The remaining part, "download=jobs.json", means add a Content-Disposition field to the response with this file name.  The webserver responds with the following content:

HTTP/1.1 200 OK
Content-type:text/plain
Cache-Control:no-cache
Content-Dis filename=jobs.json

(content data)

Firefox and Chrome do as I would expect, it puts up a file save prompt with the suggested name and lets me save the file.  IE8 asks to either open or save the file.  If I select "Open", the file is properly displayed.  If I select "Save", a pop-up appears with the flying paper sheets with:

Getting file information:
params.json from atb.qpm

Another pop-up is displayed on top of it with:

Internet Explorer can not download params.json from atb.qpm
Internet explorer was not able to open this Internet site.  The requested site is either unavailable or cannot be found.  Please try again later.

I am monitoring the HTTP traffic with Wireshark and don't see anything wrong with the content going either way.  I've also tried modifying the response header, like returning "application/octet-stream" and "Content-length" fields, but without success.

Is there any way to get this to work correctly?

---

The future isn't what is used to be.

Answer 1

There is a typo in the response, it should be:

Content-Disposition: attachment; filename=jobs.json

---

The future isn't what is used to be.

Answer 2

Hi, have tried with other IE versions, such as IE9?

Answer 3

No.  Since most of our customers will be using corporate PCs they may not have the privileges to upgrade if needed.  I need to make this feature as universal as possible, so I would like  to get this working.  My company only recently approved and forced the upgrading to IE8 from IE6, so it will likely be some time before we upgrade to IE9.

---

The future isn't what is used to be.

Answer 4

The file I am sending is quite small, only a few hundred characters.  The entire content of the file is sent in the response.  There is no other HTTP traffic after the response, so I am wondering why IE is saying it can't open the site when it already has and received a response.  The error does not make sense.

---

The future isn't what is used to be.

Answer 5

I have this issue also, just discovered it today.I know it not working because we set nocache on the response headers. It was working fine before but why it stop to work all in a sudden? Any solution/suggestion?

Answer 6

@murrellr

please try in noAddons mode....

and also in safe boot with networking...

the appearance of 'flying sheets of paper' during the download process suggests that you have a third party download manager installed that is using shell hooks.... or perhaps a custom pluggable protocol handler. (assuming xp/sp3 and IE8)or your group policy settings have disabled the IE downloads manager.

---

Rob^_^

Answer 7

The "flying sheets" still appears in noAddons and Safe mode.  I can download files from other sites.

Any other suggestions?

---

The future isn't what is used to be.

Answer 8

Hi,

its a guess, but assuming you are using https with no-cacheing...

Tools>Internet Options>Advanced tab, uncheck "Do not save encrypted files to disk"

Regards.

---

Rob^_^

Answer 9

This field is already unchecked.

---

The future isn't what is used to be.

Answer 10

I've been doing some more tests to try and characterize the problem, and have some confusing results.  Type in the following URL, the problem occurs.  This directory also has some CSV files in it, and they fail as well.

http://atb.qpm/system/spindle1/controller/data/params.json

http://atb.qpm/system/spindle1/controller/data/events.csv

However, if I browse to the folder 'http://atb.qpm/system/spindle1/controller/data/', the webserver shows a directory listing of the files.  Each file name is a hyperlink to the file, so when I click on 'params.json', the link is 'http://atb.qpm/system/spindle1/controller/data/params.json'.  This works!  Now, while displaying this page, if I manually type in the URL of params.json, this works too.

Under normal operation, the browser navigates to 'http://atb.qpm/index.html'.  On one of its subpages, which is generated dynamically in a <DIV> element, an "Export" button is presented.  When "Export" is pressed, the URL given in the original post is issued.  This fails.

So here is what I have found so far:

1.  The problem has nothing to do with the extra arguments in the URL.  It happens to any (non-HTML?) file.

2.  The problem seems to be sensitive to what page is currently being displayed compared with the file's URL.

Since I have never seen this problem with any other site, I'm guessing it may have something to do with the simple HTTP header that is being returned.  I'll post more details as I find them.

---

The future isn't what is used to be.

Answer 11

With the last Windows update, the problem has morphed.  The file save is now working, but it no longer prompts the operator.  It blindly saves the file without letting the operator change or cancel.  How do I force the browser to prompt the operator?

---

The future isn't what is used to be.

Answer 12

With this latest update, I got it to work by adding the following to the response header.  I don't know which one fixed it.

Content-type: application-download
X-Content-Type-Options: nosniff
X-Download-Options: noopen
Content-Transfer-Encoding: binary

---

The future isn't what is used to be.