Closed Bug 230272 Opened 21 years ago Closed 13 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 ago13 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: