Open
Bug 425392
Opened 17 years ago
Updated 3 years ago
Fx not using Linux OS filetype detection when uploading, relies on extension instead
Categories
(Firefox :: File Handling, defect)
Tracking
()
UNCONFIRMED
People
(Reporter: aquarius, Unassigned)
Details
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).
Updated•17 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: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..
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 !
Updated•9 years ago
|
Product: Core → Firefox
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•