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:126.96.36.199) Gecko/20071008 Ubuntu/7.10 (gutsy) Firefox/188.8.131.52 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:184.108.40.206) Gecko/20071008 Ubuntu/7.10 (gutsy) Firefox/220.127.116.11 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 18.104.22.168, 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).
15 years ago
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:22.214.171.124) 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:126.96.36.199) 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..
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 !
7 years ago
Product: Core → Firefox
6 months ago
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.