bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

Images will not display when served without a content-type header.

RESOLVED INCOMPLETE

Status

()

Firefox
File Handling
--
major
RESOLVED INCOMPLETE
11 years ago
8 years ago

People

(Reporter: Aria, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [CLOSEME 2010-11-15])

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12

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.

Comment 1

11 years ago
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?
(Reporter)

Comment 2

11 years ago
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

(Reporter)

Updated

10 years ago
Severity: normal → major
(Reporter)

Comment 3

10 years ago
Is anyone going to comment on this or shall I assume that this is not going to be addressed?

Comment 4

10 years ago
(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.