Version: (using KDE Devel) Installed from: Compiled sources IESG approved registration of the application/ecmascript and related media types. See: IANA|Text Media-Types, http://www.iana.org/assignments/media-types/text/ IANA|Application Media-Types, http://www.iana.org/assignments/media-types/application/ RFC 4329 "Scripting Media Types" defines valid MIME-Types for ECMAScript and JavaScript and marks which ones are invalid. See ftp://ftp.rfc-editor.org/in-notes/rfc4329.txt for details. The use of the former used MIME Types text/ecmascript, text/javascript and text/x-javascript is discouraged (marked obsolete) in favour of application/ecmascript (ECMAScript) and application/javascript (JavaScript). Web browsers should recognize and handle these new MIME Types correctly.
SVN commit 589296 by orlovich: Don't try to run external VBScript as ECMAScript (98216) Add a couple of symmetric mimetypes (134763) BUG:134763 BUG:98216 M +3 -1 htmltokenizer.cpp --- branches/KDE/3.5/kdelibs/khtml/html/htmltokenizer.cpp #589295:589296 @@ -395,7 +395,7 @@ CachedScript* cs = 0; // forget what we just got, load from src url instead - if ( !currentScriptSrc.isEmpty() && + if ( !currentScriptSrc.isEmpty() && javascript && (cs = parser->doc()->docLoader()->requestScript(currentScriptSrc, scriptSrcCharset) )) { cachedScript.enqueue(cs); } @@ -1153,6 +1153,8 @@ type.compare("text/ecmascript") != 0 && type.compare("text/livescript") != 0 && type.compare("application/x-javascript") != 0 && + type.compare("application/x-ecmascript") != 0 && + type.compare("application/javascript") != 0 && type.compare("application/ecmascript") != 0 ) javascript = false; } else if( a ) {
Two Questions: Why adding application/x-ecmascript -- is its occurance significant seen in the wild? What about the widespread (but now deprecated) text/javascript -- I don't see it in the patch above? Further I cite RFC 4329 "Scripting Media Types" on http://www.ietf.org/rfc/rfc4329.txt says in 3. Deployed Scripting Media Types and Compatibility: --------------------- [..] Various unregistered media types have been used in an ad-hoc fashion to label and exchange programs written in ECMAScript and JavaScript. These include: +-----------------------------------------------------+ | text/javascript | text/ecmascript | | text/javascript1.0 | text/javascript1.1 | | text/javascript1.2 | text/javascript1.3 | | text/javascript1.4 | text/javascript1.5 | | text/jscript | text/livescript | | text/x-javascript | text/x-ecmascript | | application/x-javascript | application/x-ecmascript | | application/javascript | application/ecmascript | +-----------------------------------------------------+ Use of the "text" top-level type for this kind of content is known to be problematic. This document thus defines text/javascript and text/ ecmascript but marks them as "obsolete". Use of experimental and unregistered media types, as listed in part above, is discouraged. The media types, * application/javascript * application/ecmascript which are also defined in this document, are intended for common use and should be used instead. [..] --------------------- Dealing with x-prefixed Subtypes: RFC 2048 "2.1.4. Special `x.' Tree" on http://www.ietf.org/rfc/rfc2048.txt discourages the use of x-prefixed MIME Types/Subtypes, especially if there is a public registered equivalent available. To watch, how others like Apache or Mozilla deal with application/x-javascript and application/x-ecmascript, see also Apache Bug 40299 "ECMAScript and JavaScript media types in mime.types file" with additional patch on http://issues.apache.org/bugzilla/show_bug.cgi?id=40299 and Mozilla Bug 62485 "script type="text/ecmascript" is not recognized" on https://bugzilla.mozilla.org/show_bug.cgi?id=62485 .
text/javascript is in the code, just not in the context of the diff. For the other one: I added it because I trusted the RFC on people using it ("significant use" is irrelevant). I may remove it again since it seems that Opera is the only one accepting it, so accepting it may cause interoperability problems with the browser duopoly. Everything else you quoted is irrelevant here --- we accept content, not produce it. What we will also NOT do is misrender websites because of pedanticisms or in a vain attempt to promote someone's notion of proper behavior. That just screws over our users, and website producers don't give a damn anyway.
Maksim, Thanks for your diff code, which seems to be checked into the trunk. I hope, it will make it soon into the next coming release of Konqueror (hopefully also into Safari). The bug seems to be resolved for me, and I mark it as resolved. It may be opened again, if necessary.