Closed Bug 155530 Opened 23 years ago Closed 23 years ago

Content-type specified by META HTTP-EQUIV ignored when server reports text/plain

Categories

(Core :: Networking: HTTP, defect)

x86
All
defect
Not set
normal

Tracking

()

VERIFIED INVALID

People

(Reporter: aleksander.adamowski, Assigned: darin.moz)

References

()

Details

The URL shown here gives a page where a misconfigured server specifies text/plain content type. However, it returns HTML code, and there's a META tag that speicifes text/html: <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Internet Explorer 6 honors that META tag and displays the page as HTML. It apparently tries to find a META HTTP-EQUIV tag in all files that have their top-level media type declared as text (I'd guess it only scans their initial ~100 bytes to reduce overhead processing), and if it's html, treat it as text/html. I propose that similar media type checking be implemented in Mozilla. The implementation has to be carefully thought out to avoid security problems - for example, the explosion of Nimda worm was possible because Internet Explorer/Outlook Express has a flawed model of content-type determination. The mail message declared audio/x-wav content type for the file, but its extension was .exe. When the file was passed to media player from Outlook Express (according to declared content type), media player run it as an executable (according to its extension). Similar dangers may be present when this feature is implemented.
*** Bug 155529 has been marked as a duplicate of this bug. ***
CCing Mitch since implementing this feature needs to be well thought out WRT security.
I think we should not do this, for several reasons: 1) IE will also show such pages as HTML if you take the META tag out (try it!) 2) http://www.w3.org/TR/html401/struct/global.html#edef-META says: The http-equiv attribute can be used in place of the name attribute and has a special significance when documents are retrieved via the Hypertext Transfer Protocol (HTTP). HTTP servers may use the property name specified by the http-equiv attribute to create an [RFC822]-style header in the HTTP response. In other words, that <meta> tag gives the content author the ability to influence what the server sends. If the server then overrides that setting, we should follow the server, IMO. Finally, consider a text document that contains something like: 'This is a tutorial. To make decent web servers send your page as HTML, you can add <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> inside the <head> element of your page. The server should then send it as HTML.' Try and see what IE shows that as when it's served as text/plain. Consider what your proposal would lead to in this case.
Hmmm... That was enlightening. Thanks, Boris! Closing bug and sorry for spam.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
verifying based on reporter's and bz's comments
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.