Closed Bug 230272 Opened 21 years ago Closed 14 years ago

citizen-electronics.com - HTML files sent as image/jpeg

Categories

(Tech Evangelism Graveyard :: English US, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: rouben, Unassigned)

References

()

Details

Attachments

(2 files)

User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 MultiZilla/1.5.0.4h Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 MultiZilla/1.5.0.4h The web server for http://www.citizen-electronics.com/ has misconfigured MimeTypes; it reports "image/jpeg" for documents where "text/html" is the correct Content-Type. As a result, Mozilla doesn't attempt to render the web page, and displays the error message "The image “http://www.citizen-electronics.com/” cannot be displayed, because it contains errors.". Microsoft Internet Explorer 6.0 assumes "text/html" even though the web server reported "image/jpeg" and renders the page properly. Reproducible: Always Steps to Reproduce: Navigate to http://www.citizen-electronics.com/ with Mozilla. Actual Results: When trying to load the URL http://www.citizen-electronics.com/ Mozilla displays the following error message instead and in place of the actual web site: ----- START OF EXACT TEXT OF ERROR MESSAGE ----- The image “http://www.citizen-electronics.com/” cannot be displayed, because it contains errors. ----- END OF EXACT TEXT OF ERROR MESSAGE ----- The message above appears in the default "Serif" type font (as defined in preferences; in my case "Times New Roman") and appears to be just a plain text message (not an image, possibly HTML-based). The actual text of the error message appears in the same place where web pages are normally rendered and does NOT show up anywhere else (e.g. on the status bar and/or as a dialog box). Expected Results: When a MimeType is misreported by the web server, Mozilla should try to do some checking of its own (through MimeMagic or a similar mechanism) in case it finds problems with the data received from the web server. At the very least Mozilla should check for text/html and text/plain and if a positive match is made, try to render the page, ignoring the potentially invalid Content-Type header supplied by the web server. Suggestion for a solution: ========================== Here's a simple snipplet of pseudocode to resolve the issue (C-ish syntax): ----- START OF PSEUDOCODE EXAMPLE ----- reportedMimeType = getMimeTypeFromWebServerResponse(incomingData); detectedMimeType = checkMimeType(incomingData); if (reportedMimeType != detectedMimeType) { /* The next line could be useful, so the user can */ /* inform the webmaster of the site that there */ /* are server problems. */ warnUserOfMisconfiguredServer(); if (detectedMimeType == 'text/html') { renderAsHTML(incomingData); } else // if (detectedMimeType != 'text/html') { promptUserToDownloadFile(incomingData); } } // endif (reportedMimeType != detectedMimeType) ----- END OF PSEUDOCODE EXAMPLE ----- Personal opinion: ================= On a more personal note: it's not a secret that most web sites on the web are made with Internet Explorer in mind. This issue does not seem to affect Internet Explorer versions 5 and 6 on the Microsoft Windows platform (not sure about Mac OS Classic/X). I completely understand that this is a server configuration issue, and an HTTP RFC violation on top of that, however, one has to keep in mind that this issue can severely limit Mozilla users from viewing certain web sites. As a result, Mozilla's reputation and popularity will suffer. In my opinion, this issue should be definitely resolved.
This is a screenshot of the PageInfo dialog ("View" menu --> "Page Info" menu item) for the URL http://www.citizen-electronics.com/ under Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 MultiZilla/1.5.0.4h.
This is a screenshot of the Mozilla browser component attempting to render http://www.citizen-electronics.com/ unsuccessfully. User-agent string: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 MultiZilla/1.5.0.4h.
We CAN guess the type. We just don't, since that would be a blatant violation of the specs involved. And we have no plans to start. To evang to contact the server maintainer.
Assignee: file-handling → english-us
Status: UNCONFIRMED → NEW
Component: File Handling → English US
Ever confirmed: true
Product: Browser → Tech Evangelism
QA Contact: ian → english-us
Version: Trunk → unspecified
For the record, Opera also just assumes it is an image.
By the way, Rouben, if you're interested, there are dozens of bugs filed on this issue already; mostly resolved duplicate or invalid... they give more extensive reasons for why we don't do this MIME type guessing.
First of all, thank you all for your feedback. I can guess how frustrating it must be answering identical bug reports over and over again with practically the same canned response. I've browsed through bugs related/identical to mine, and unfortunately I was unable to find a satisfactory response. Again, I apologize in advance if I missed something. Thank you for your understanding. Despite the fact that implementing mimetype guessing will be considered as breaking HTTP specs, at this point, I think it's a rather necessary evil. I can put forth a plethora of reasons why I think this is necessary, but I'll focus on the most important points instead: 0. Regular users couldn't care less *why* a page is not being displayed properly. If it doesn't work for them, they will switch browsers. Period. I don't think that's in anyone's best interests. 1. Most webmasters don't know what they are doing. There are a lot more misconfigured web servers on the web than you might think (no offence intended). 2. Webmasters that don't know what they are doing usually don't fix any of their problems, either because they don't know how, or because they simply don't care. [OFFTOPIC] A very blatant example is located at http://www.torontoprometric.com/Bookings/BookingRequest.htm (not related to this issue, but a quick glance at what is requested in the form and at the way form submission is implemented will give you an idea; by the way that web site is a "monopoly" for TOEFL testing in Toronto, Canada, and I am considering reporting them to VISA and MasterCard for willingly running an insecure form). 3. Finally, I am willing to bet that Netscape/AOL will probably implement this in their releases of the browser anyway (they already bundled it with so much junk that this will probably be a non-issue for them). Having said the above, I completely understand and respect the standards involved here. I'm all for these standards, and I really do believe that the Internet would have been a much better place if everyone and everything followed standards to the letter. However, the world (and the Internet) is not at all a perfect place. And when something is imperfect, you can either adjust or go down in flames. Unfortunately you seem to choose the latter. Even more philosophically: this is a matter of "evolution", if you will, whereby the environment has changed (misconfigured web server) and in order to "survive" Mozilla needs to adapt (implement mimetype guessing). If it doesn't adapt, it will not "survive". By the same token, popup blocking is also a violation of standards, because according to JavaScript specs, a window.open() means that a browser should open a new window, and Mozilla clearly doesn't do that with popup blocking turned on (in certain cases). This is a violation of standards, but it was a necessary evil. Mimetype guessing is in the same position at this point. I strongly urge you to reconsider this issue. In my opinion, the perfect way to do this, is to implement a boolean config value that triggers mimetype guessing behaviour. Leave it disabled by default, if you wish, but *do* have the option to enable it.
OS: Windows 98 → All
Severity: normal → major
Rouben, the problems with mimetype guessing are as follows: 1) Will break a number of sites that serve up content that looks like one type of data but is being sent as another (and is meant to be interpreted as another). Bugzilla itself is an example -- a lot of crash testcases are served up as text/plain to keep people from accidentally crashing. For a lot of these sites IE does not matter, really, so they can assume no guessing happens (since no other browser really does it). 2) MIME type guessing can lead to security holes when security systems allow through content deemed "safe" because of its type. This includes security systems both internal and external to Mozilla. We appreciate the issues involved, and we recently _did_ start treating some text/plain pages as application/octet-stream because Apache's default configuration is so broken. That covers almost every single report we have ever received on the issue, and the goal is to provide maximum usability with minimum non-conformance (exactly like the popup blocker -- we don't disable _all_ window.open calls). Netscape/AOL are not likely to ship another release, really. Netscape is no more and AOL is not interested. Finally, IE is about to ship a service pack which removes a significant amount of MIME type sniffing from that browser. That will likely radically affect the situation existing on the internet today.
Severity: major → normal
Thanks very much for this explanation. I sincerely hope that when Microsoft makes their browser a bit more standard compliant that will force some web site operators to put some more thought into their web sites and web server configurations. Again, thank you very much for your time and troubles.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
as this is an evangelism bug, it is not invalid.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Summary: Browser unable to guess correct MimeType when web server reports incorrect MimeTypes → citizen-electronics.com - HTML files sent as image/jpeg
[bug248549notfixed]
INCOMPLETE due to lack of activity since the end of 2009. If someone is willing to investigate the issues raised in this bug to determine whether they still exist, *and* work with the site in question to fix any existing issues, please feel free to re-open and assign to yourself. Sorry for the bugspam; filter on "NO MORE PRE-2010 TE BUGS" to remove.
Status: REOPENED → RESOLVED
Closed: 21 years ago14 years ago
Resolution: --- → INCOMPLETE
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: