613727 - Wrong media type displayed for missing Content-Type.

Status: RESOLVED WORKSFORME

(Firefox :: File Handling, defect)

Description

[Tim Bannister]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12

This is a near-duplicate of bug 491869

When accessing a resource which has no Content-Type header, Firefox will guess the metadata. However, the way this is presented to the user depends on whether the URI includes a file extension.

For the case with a file extension, the document is presented with a specific media type and there is no clue for the user that this has been guessed.

URIs that demonstrate these behaviours:
http://sharing.c8h10n4o2.org.uk/Debian.FAQ
http://sharing.c8h10n4o2.org.uk/Debian%20FAQ

Reproducible: Always

Steps to Reproduce:
Visit http://sharing.c8h10n4o2.org.uk/Debian.FAQ
Actual Results:  
You have chosen to open:
Debian.FAQ
which is a: application.pdf

Expected Results:  
You have chosen to open:
Debian.FAQ
which is a: Preview document

Compare result for http://sharing.c8h10n4o2.org.uk/Debian%20FAQ

Comment 1

[Tim Bannister]

Attachment: Screen shot showing unexpected behaviour

Comment 2

[Tim Bannister]

Both URIs give the same HTTP response, here are the headers:

HTTP/1.1 200 OK
Date: Sat, 20 Nov 2010 14:05:27 GMT
Server: Apache/2.2
Last-Modified: Sat, 20 Nov 2010 13:53:11 GMT
ETag: "82c9-811fc-4957c57f4ffc0"
Accept-Ranges: bytes
Content-Length: 528892

Comment 3

[Matthias Versen [:Matti]]

I'm not sure what you want to report here.
a) That the guessed content-type depends on the file extension ?
That is by design:
from RFC 2616
>Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type 
>header field defining the media type of that body. If and only if the media 
>type is not given by a Content-Type field, the recipient MAY attempt to guess 
>the media type via inspection of its content and/or the name extension(s) of 
>the URI used to identify the resource. If the media type remains unknown, the 
>recipient SHOULD treat it as type "application/octet-stream". 

b) that the guessing is wrong
guessing isn't always right and that is a good reason why the server should provide the content-type. Both URLs are detected as PDF File in my case with SM trunk on win32

c) that there is no message that the content-type is guessed ?
That is AFAIK a wontfix for Firefox.

Comment 4

[Boris Zbarsky [:bzbarsky]]

There's no core bug here.  There's no Content-Type header on the response, so we sniff it as a PDF (per that HTTP spec bit cited in comment 3).  What the UI then decides to do is its business.

Note that PDF is one of the types we detect by magic number; we never use the extension for sniffing in this case.  So any differences based on extension here are pure UI artifacts.

Comment 5

[Manuela Muntean [Away]]

Marking this WFM based on comment 4.