This site will have limited functionality while we undergo maintenance to improve your experience. If an article doesn't solve your issue and you want to ask a question, we have our support community waiting to help you at @FirefoxSupport on Twitter and/r/firefox on Reddit.

Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Issue with .do files in Firefox

  • 8 replies
  • 1 has this problem
  • 4 views
  • Paskiausią atsakymą parašė cor-el

more options

Hi all.

I have seen many websites where this issue has been discussed but no resolution.

We had been using Chrome but made a decision to instead use Firefox for privacy reasons.

At work we have websites that generate PDF files with the name xmlreport.do (we have no control over this). Chrome seems to recognise these .do files as pdf files and offers to save them as such, Firefox does not.

Our users are annoyed as there are now extra steps required to change the File Type box to show all the existing pdf files in the download folder so they can more easily rename the file (they click once on an old file then change the date in the file name).

Is there a reason Chrome and Firefox treat these differently? Does Chrome read the file header so it knows what the file actually is (kind of like Irfanview does with images)? Can Firefox be made to do the same?

thanks

jc

Hi all. I have seen many websites where this issue has been discussed but no resolution. We had been using Chrome but made a decision to instead use Firefox for privacy reasons. At work we have websites that generate PDF files with the name xmlreport.do (we have no control over this). Chrome seems to recognise these .do files as pdf files and offers to save them as such, Firefox does not. Our users are annoyed as there are now extra steps required to change the File Type box to show all the existing pdf files in the download folder so they can more easily rename the file (they click once on an old file then change the date in the file name). Is there a reason Chrome and Firefox treat these differently? Does Chrome read the file header so it knows what the file actually is (kind of like Irfanview does with images)? Can Firefox be made to do the same? thanks jc

All Replies (8)

more options

Firefox doesn't do content sniffing for downloading files AFAIK. What matters to Firefox is what content type the server sends via the HTTP response headers and it is not likely that a server will send a .do file as application/pdf as would be required recognize a PDF file and offer to save it as such.

You can check the HTTP response headers via the network monitor.

You can look at this extension created by contributor jscher2000:

more options

Hi jcrowingAHHHHHHHHHHHHHHHHHHHHH, this may be a little complicated to work around if the server uses .do on the ends of other types of file names as well (for example, its HTML pages). In that case, Firefox (or an add-on) can't assume that .do = PDF file, it would need to consider other indicia such as the full file name or a Content-Disposition header instructing Firefox to download the file instead of opening it in a tab.

more options

I assumed that the server only sends these PDF files with a .do file extension. If other files are send as well with this file extension then you are out of luck, but if you get a download dialog then I assume that the server sends a generic content type like "application/octet-stream".

more options

Hey everyone, thanks for the replies.

One website in question reports the xmlreport.do file content-type as application/pdf. And yes there are other file types utilised with .do extension, so marking all .do files as pdf's would break the website.

When using Chrome it previews the file in-browser automatically and when you click Save it offers to save the report as xmlreport.do.pdf.

Firefox just comes up with the Save or Open dialog with the file title as xmlreport.do.

We have another site that offers pdf reports as reportitle.html. The header has the content-type set as application/pdf. Chrome displays it as a PDF in-browser; Firefox displays it as html... so you can imagine what it looks like.

It seems Firefox (69.0.1 tested on Win 7 and 10) is ignoring the content-type in the header and going by the file extension; or perhaps favouring the file extension over the header.

cheers

jc

more options

If the file is send as application/pdf then Firefox should open it in a tab in case the builtin PDF Viewer is enabled.

Did you verify this with the Network Monitor or with the Web Console with Network enabled like I suggested above ?

If you always get a download dialog then is sounds that you have disabled the PDF Viewer. Make sure you haven't disabled the viewer.

more options

Via Web Console Network monitor. Here is the reported header:

HTTP/1.1 200 OK Date: Mon, 30 Sep 2019 02:55:05 GMT Server: Apache/2.2.15 (Red Hat) Pragma: No-cache Cache-Control: no-cache,no-store,max-age=0,must-revalidate,proxy-revalidate Expires: 0 Content-Length: 11930 Content-Disposition: :attachment;inline Connection: close Content-Type: application/pdf Content-Language: en-AU

I note the line: Content-Disposition: :attachment;inline

So is Firefox just seeing the attachment parameter and showing the Save dialog? Chrome sees the same header and seems to ignore the attachment parameter and show it inline. Is there an issue with that double full colon?

Firefox's internal PDF viewer is definitely enabled. Other pdf documents show in-browser fine.

cheers

jc

more options

Hi jc, that header value is so wrong. You could try an extension that overrides the "attachment" disposition so Firefox opens the PDF in a tab. I'm not sure that will help with the ultimate problem of Firefox not knowing to suggest a .pdf file extension, but maybe?

I'll suggest mine, since it's so easy to turn on when you need it and off when you don't:

https://addons.mozilla.org/firefox/addon/content-type-fixer/

To turn it on, click the Zzzz button on the toolbar, then click it again to drop its menu and change the Content-Disposition Override setting to "Allow viewing in a tab".

Once you are done overriding, you can change that setting back to "As set by the server" and/or click Stop Listening and Clear Log.

Now, I must confess, I've never tried using it with such a weird header value, so I'm curious what will happen!

more options