User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0 Build ID: 20150122214805 Steps to reproduce: I've tried downloading several jar files from various sources. Actual results: Firefox always saves them in the form <filename>.jar.zip Expected results: These files should be saved as .jar, which is the correct extension.
Also, take a look at the following URLs: http://www.reddit.com/r/feedthebeast/comments/2inh6t/cant_get_dragonapi_and_rotarycraft_to_work_ive/clckt2m http://osu.ppy.sh/forum/t/55305 This would suggest the problem has existed for as long as four years. I assume the only reason it's never been brought up is that relatively few people download .jar files to save to disk.
Component: Untriaged → Downloads Panel
Do you downloaded the files or opened them with an application ? Do you have an example public link to such a jar file that produces this error ?
I first noticed it with http://www.mediafire.com/download/0cedmhi2m6r3e46/DragonAPI_1.7.10_V4b.jar
>HTTP request sent, awaiting response... > HTTP/1.1 200 OK > Server: LRBD-bigdownload- > Date: Sat, 14 Feb 2015 21:04:30 GMT > Connection: close > Accept-Ranges: bytes > Content-transfer-encoding: binary > Content-Length: 1410729 > Content-Disposition: attachment; filename="DragonAPI 1.7.10 V4b.jar" > Content-Type: application/zip The server tells us that this file is in fact a zip file with the content-type. That the .zip extensions is added when you open the file with a helper application is expected. Just downloading the file doesn't change the file extension for me with Firefox35 on Windows7.
The server interprets it as application/zip because a JAR is literally just a specially-structured ZIP file. I would suggest that FF should in this specific instance use the extension specified by the Content-Disposition and not the Content-Type. Now, some logic could be used so that, when an application/zip file is detected, to check the suggested filename and, if the extension is indeed a type of ZIP file, to give it the extension suggested there. I know several other typed of files, like most MS Office files, are also ZIPs, so perhaps this behavior could be applied to them too.
> I know several other typed of files, like most MS Office files, are also ZIPs, so perhaps this behavior could be applied to them too. Firefox and all other good browsers don't check the content of the file because it's dangerous, forbidden by the http RFC and inconsistent. The webserver tells us what kind of the it sends with the content-type header. The extension of the file doesn't matter from the browsers point of view. The browser looks and changes the extension only if you open a file with a helper application. The reason is simple: If you open a application/zip file with a helper application like 7-zip and the extension is for example .czf, the helper application can reject the file. btw: The right content-type for jar files is afaik application/java-archive
I didn't suggest the file type handling of FF be affected by type-probing voodoo. I merely suggested that for save to disk operations, the default extension be based on the server-suggested filename unless something is grossly out of whack. The revised filename handler would be only triggered by an application/zip MIME type, and would therefore still be fundamentally following the server's lead, it would just use additional information to suggest an extension for the user to save it as.
You need to log in before you can comment on or make changes to this bug.