搜索 | 用户支持

防范以用户支持为名的诈骗。我们绝对不会要求您拨打电话或发送短信,及提供任何个人信息。请使用“举报滥用”选项报告涉及违规的行为。

详细了解

Issue with .do files in Firefox

  • 8 个回答
  • 1 人有此问题
  • 4 次查看
  • 最后回复者为 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

所有回复 (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