416094 - Content-type application/pdf not recognized if no .pdf extension

Status: RESOLVED WORKSFORME

(Firefox :: File Handling, defect)

Description

[Vincent Lefevre]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
Build Identifier: 

Under some conditions (probably when the filename doesn't have an extension), the content-type is not recognized by Firefox and it is impossible to view the file. One can only save the file on the disk, but Firefox doesn't even honor the Content-Location HTTP header (so that the file is saved without an extension).

Reproducible: Always

Steps to Reproduce:
1. Open http://www.vinc17.org/research/publi.en.html
2. Click on the link of the first publication ("Toward the integration..."); this corresponds to the above URL.
Actual Results:  
Firefox opens a dialog box saying: You have chosen to open casc2004 which is a: application/pdf from: ... What should Firefox do with this file?
* Open with [Choose...]
...

Expected Results:  
It should have said "... which is a: Portable Document Format" and "Open with Preview (default)". This is what I obtain when I click on the "PDF" link just below. AFAIK, the only significant difference is the ".pdf" filename extension in the second case.

FYI, here are the headers I obtain with wget -S (I don't think they should be much different with Firefox):

* First link (casc2004):
  HTTP/1.1 200 OK
  Date: Thu, 07 Feb 2008 09:08:51 GMT
  Server: Apache/1.3.33 (Debian GNU/Linux)
  Content-Location: casc2004.pdf
  Vary: negotiate,accept,accept-encoding
  TCN: choice
  Last-Modified: Thu, 17 May 2007 20:35:56 GMT
  ETag: "4116b-26eb4-464cbcac;46ddd7f5"
  Accept-Ranges: bytes
  Content-Length: 159412
  Keep-Alive: timeout=15, max=100
  Connection: Keep-Alive
  Content-Type: application/pdf
  Expires: Thu, 07 Feb 2008 09:08:51 GMT
Length: 159412 (156K) [application/pdf]

* Second link (casc2004.pdf):
  HTTP/1.1 200 OK
  Date: Thu, 07 Feb 2008 09:04:09 GMT
  Server: Apache/1.3.33 (Debian GNU/Linux)
  Last-Modified: Thu, 17 May 2007 20:35:56 GMT
  ETag: "4116b-26eb4-464cbcac"
  Accept-Ranges: bytes
  Content-Length: 159412
  Keep-Alive: timeout=15, max=100
  Connection: Keep-Alive
  Content-Type: application/pdf
Length: 159412 (156K) [application/pdf]

Comment 1

[Vincent Lefevre]

Note: I don't have this problem under Linux.

Comment 2

[Duncan Berriman]

I also experienced this problem.

As a workaround until it is fixed you can add the following to your http headers.

Content-Disposition: filename="xxx.pdf"

replacing xxx with an appropriate file name!

This doesn't appear to cause any issues with any other browsers I've tried and gives firefox on Mac the file extension it requires.

Comment 3

[Vincent Lefevre]

Unfortunately I can't try any browser, and since this header is invalid (according to RFC 2616 (HTTP 1.1), there must be a disposition-type, but this is a also problem with Firefox (bug 185618)), I don't want to add it just because there's a bug in Firefox.

Comment 4

[Duncan Berriman]

Hadn't realised that was required. You can use.

Content-Disposition: inline; filename="xxx.pdf"

Appears to cause no issues, works as expected in Firefox and IE on a PC and Safari and Firefox on a Mac.

I agree with your sentiments re not adding it but just thought I'd post this workaround to help out those who need to get it working in the short term.

Comment 5

[Vincent Lefevre]

OK, I've just seen this was suggested in bug 185618.

I don't remember exactly, but I think that if I want to save the file to disk (instead of opening it with some application), Firefox doesn't add an extension, even under Linux. This could also be a workaround for that too, as the extension is needed in practice. However, automatically adding the extension on OS's that don't have file types should probably be a RFE.

Now I have to find how to do that automatically at the server level (for both Apache 1 and Apache 2).

Comment 6

[Duncan Berriman]

You could change inline to attachment to force download rather than using an application but it doesn't seem to work the same on all browsers.

IE on PC, does download
Firefox on PC does download
Firefox on Mac works the same as inline (option to open/download)
Safari on Mac downloads it and then opens it

All honour the filename given.

Luckily my pdf's are produced by cgi so I can simply add another line where I output the Content-Type in the cgi.

Comment 7

[Vincent Lefevre]

In fact I want the same behavior as without the Content-Disposition header (except that if the user requested that the file to be saved, the filename should have the extension corresponding to its type[*]). So, I think that "inline" is the best.

[*] This may be rather tricky, since when the user wants to download (with Save Page As) file.html and the real filename is file.html.fr, then the .fr extension should not be part of the suggested filename. But if the user wants to download "file" and the real filename is "file.pdf" (because HTTP content negotiation is used), then the suggested filename should be "file.pdf".

Of course, this is just a workaround, and things related to mapping between MIME types and filename extensions / file types (when available on the client OS) should be done by the user agent, not by the server.

Comment 8

[Arthur Prokosch]

(In reply to comment #3)
> Unfortunately I can't try any browser, and since this header is invalid
> (according to RFC 2616 (HTTP 1.1), there must be a disposition-type,

Where do you see that requirement in RFC 2616?  I went through pretty closely (read, searched for every occurrence of "Disposition") and found only...

Section 15.5: 
  "Content-Disposition is not part of
   the HTTP standard, but since it is widely implemented, we are
   documenting its use and risks for implementors."

Section 19.5.1:
   "The Content-Disposition response-header field has been proposed as a
   means for the origin server to suggest a default filename if the user
   requests that the content is saved to a file."
with no occurrences of "MUST", and "SHOULD" only referring to UA behavior.

Comment 9

[Vincent Lefevre]

This is in the grammar:

        content-disposition = "Content-Disposition" ":"
                              disposition-type *( ";" disposition-parm )

Comment 10

[Arthur Prokosch]

(In reply to comment #9)
Of course.  I misinterpreted your comment.

RFC 2616 still doesn't require Content-Disposition: be present at all (only that, if present, it be formatted properly). Thus, Firefox/Mac's behavior is still a bug.

Comment 12

[Thomas Bertels]

The former bug URL Content-Type has changed to application/postscript, so I modified it to http://bcc.nbb.be/BCCIA0101/WEB/actions/startbcc?lang=E

Steps to reproduce:
1. The popup blocker should be disabled or nbb.be added as an exception.
2. Open http://bcc.nbb.be/BCCIA0101/WEB/actions/startbcc?lang=E
3. Enter "test" (without ") in the text box next to "By a word in the name" and press enter.
4. Click on the first result.
5. Click on the first download link under "PDF on-line".

HTTP headers:

http://bcc.nbb.be/BCCIA0101/WEB/actions/DownloadPDF

GET /BCCIA0101/WEB/actions/DownloadPDF HTTP/1.1
Host: bcc.nbb.be
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:30.0) Gecko/20100101 Firefox/30.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr-fr,fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Referer: http://bcc.nbb.be/BCCIA0101/WEB/actions/SendB2B?&mfref=201041200154&cdref=20100818021
Cookie: [removed to avoid clutter]
Connection: keep-alive

HTTP/1.1 200 OK
X-Powered-By: Servlet/3.0
Content-Type: application/pdf
Content-Language: en-UK
Date: Mon, 14 Jul 2014 11:45:36 GMT
Transfer-Encoding: chunked

Comment 13

[Thomas Bertels]

Attachment: pdf Windows workaround

Windows workaround found at http://helpx.adobe.com/acrobat/kb/pdf-files-dont-display-some.html

Adds a [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\MIME\Database\Content Type\application/pdf]
"Extension"=".pdf" registry key

Comment 14

[Vincent Lefevre]

The bug URL at bcc.nbb.be was no longer valid. I've updated it to one that works and always serves the file as application/pdf. The bug is no longer reproducible with Firefox 45.2.0 under Linux. So, WFM.

Note that http://www.vinc17.org/research/papers/casc2004 is still valid if the browser is configured to prefer PDF to PS via network.http.accept.default, e.g. with the value: application/xhtml+xml;q=0.95,text/html;q=0.9,text/xml;q=0.85,application/xml;q=0.85,text/plain;q=0.8,image/png,application/pdf;q=0.9,application/postscript;q=0.8,*/*;q=0.5

With this URL, there's an additional header "Content-Location:" (due to the fact that HTTP negotiation is used by the server). In case this header could have an effect, I've also tested this URL and I can't reproduce the bug either.