Open Bug 425392 Opened 15 years ago Updated 6 months ago

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


(Firefox :: File Handling, defect)






(Reporter: aquarius, Unassigned)


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

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, take any JPEG file called whatever.jpg, and copy it to "whatever" (no file extension).
2. Go to 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).
Component: General → File Handling
Product: Firefox → Core
QA Contact: general → file-handling
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: 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: 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"

#!/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..
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 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

Very thankful if you can have a take on it !
Product: Core → Firefox
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.