Please report any other irregularities here.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168) Gecko/20080201 Firefox/22.214.171.124 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/20080201 Firefox/188.8.131.52 I have an application that serves HTML and JPG content. The application serves HTML with a proper content-type header but when it serves JPG images, it serves them with NO content-type header. I have not way to change the application server. This causes Firefox to display the broken link image instead of the image served. IE displays images without problem. This effect has existed in all Firefox versions. Thanks. Reproducible: Always Steps to Reproduce: 1.Internal application server. Can't provide a public example. 2. 3.
This is probably a WONTFIX. Perhaps a modification of the "Open in browser" extension http://www.spasche.net/mozilla/ would let it show images inline?
I had already tried the "open in browser" extension but it does not resolve the problem because Firefox ignores these images and does not give the plugin a chance to prompt on how to deal with the file. If I request the URL for a GIF image directly as in http://host/image.gif then firefox either displays a blank page with "Done" at the bottom left corner OR it will display the text: "The image “http://host/image.gif” cannot be displayed, because it contains errors." in an otherwise blank page. Since the original request from Firefox was for a '.gif' file, why can't firefox assume that the returned content is of type image/gif? This seems to be the behavior of IE at least. It only seems logical for it to do so. Thanks
Is anyone going to comment on this or shall I assume that this is not going to be addressed?
(In reply to comment #2) > Since the original request from Firefox was for a '.gif' file, why can't > firefox assume that the returned content is of type image/gif? This seems to > be the behavior of IE at least. It only seems logical for it to do so. Probably for security reasons, since anything can be added to the end of the filename of arbitrary binary files, it could be a delivery method for malware making such assumptive behaviour unsafe (you'd need to find someone that actually knows about the details to gauge the accuracy of that guess). Beyond that is content sniffing, covered at http://developer.mozilla.org/en/docs/How_Mozilla_determines_MIME_Types#ExternalHelperAppService
This bug was reported using Firefox 3.0 or older, which is no longer supported. The bug has also not been changed in over 500 days and is still in UNCO. Reporter, please retest this bug in Firefox 3.6.10 or later using a fresh profile, http://support.mozilla.com/en-US/kb/managing+profiles. If you still see this problem, please update the bug. If you no longer see the bug, please set the resolution to RESOLVED, WORKSFORME. This is a mass search of unconfirmed bugs that have no activity on them, so if you feel a bug was marked in error, just remove the CLOSEME comment in the whiteboard within the next month.
Whiteboard: [CLOSEME 2010-11-15]
No reply, INCOMPLETE. Please retest with Firefox 3.6.12 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.