425392 - Fx not using Linux OS filetype detection when uploading, relies on extension instead

Status: UNCONFIRMED

(Firefox :: File Handling, defect)

Description

[Stuart Langridge]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.6) Gecko/20071008 Ubuntu/7.10 (gutsy) Firefox/2.0.0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.6) Gecko/20071008 Ubuntu/7.10 (gutsy) Firefox/2.0.0.6

When uploading a jpeg named "foo" through an <input type="file"> multipart/form-data HTML form, Fx passes the content-type in the multipart section as application/octet-stream. When uploading exactly the same file, but with that file named "foo.jpg", Fx passes the multipart content-type as image/jpeg. My OS knows how to diagnose a file's content-type without relying on its extension; Fx should use this OS level filetype diagnosis instead of relying on the extension.

Reproducible: Always

Steps to Reproduce:
1. On Ubuntu, with Fx 2.0.0.6, take any JPEG file called whatever.jpg, and copy it to "whatever" (no file extension).
2. Go to http://validator.w3.org/ and click Validate by File Upload
3. Upload whatever.jpg and say Check
4. Note that it says "Sorry, I am unable to validate this document because its content type is image/jpeg, which is not currently supported by this service." -- correctly image/jpeg.
5. Do the same but upload "whatever" (without file extension)
4. Note that it says "Sorry, I am unable to validate this document because its content type is application/octet-stream, which is not currently supported by this service." -- content-type is different for the same file, which means that Fx is identifying the content-type from the file extension, which is not the way to do it on Linux.


Expected Results:  
Used the OS-level filetype identifiers (libmagic).

Comment 1

[mre]

having related problems though a bit different, i guess both bugs could profit from the same fix - I experience this using "Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.8) Gecko/20100723 Ubuntu/10.04 (lucid) Firefox/3.6.8"

Reproducable: Always

Just name files on the os-fx setup like described above and use uncommon file-extensions... upload and and check the Content-Type Attribute of the Part

:Bad Request looks like:

POST /core/command HTTP/1.1 
Host: localhost:7557
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.8) Gecko/20100723 Ubuntu/10.04 (lucid) Firefox/3.6.8
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://localhost:7557/de.deepamehta.3-client/index.html
Cookie: workspace_id=53
Content-Type: multipart/form-data; boundary=---------------------------1286776619979806657668902151
Content-Length: 3512-----------------------------1286776619979806657668902151
Content-Disposition: form-data; name="file"; filename="inkscape.desktop"
Content-Type: 

#!/usr/bin/env xdg-open

----- Test Reports --

Filename	The Part's Content-Type	 Firefox Chrome

Text.json	                         BAD	OK	

Text.txt	text/plain	         OK	OK	

some.log	text/x-log	         OK	OK	

examples.desktop	                 BAD	OK	

yzyx.jpg	image/jpeg	         OK	OK	

app.jnlp	application/x-java-jnlp-file	OK	OK	

Unsaved Document	????? Request is invisible, not tracked by Firebug but server says: (application/octet-stream)	OK	OK
----------

The special thing is that "Unsaved Documents" without a file-extension are OK as they are  (application/octet-stream) though are not tracked by Firebug... this should be the fallback as in rfc mentioned above for every unknown file-extension.. but this won't happen i guess if the suggestions from above are taken into account..

Comment 2

[mre]

Sorry for being unclear and reporting my usage of confusing filenames like "Unsaved Document". This addition for clarification:

The Fact is: Jetty Server was used for testing.
The Point is: Firefox does not set "Content-Type" for unknown files.

I also forgot to link to the RFC which pointed out to me that there might be a problem realted to different interpretations of what SHOULD be
At http://www.ietf.org/rfc/rfc1867.txt is written in 3.3:

   Each part should be labelled with an appropriate
   content-type if the media type is known (e.g., inferred from the file
   extension or operating system typing information) or as
   application/octet-stream.

Very thankful if you can have a take on it !