This seems like something that Timo and Lego might be interested in.

Nowadays, we do know the content model of a page and if action=raw is requested and no ctype= is given in URL and content model is suggesting a MIME type like text/javascript or text/css or others, the answer should set appropriate Content-Type, otherwise text/x-wiki as practised by our forefathers.

Well its probably safe for css/js, but I would be cautious about the more general case. For example, with the plain text content model - I'm not sure what the browser sniffing rules actually are, but I think some browsers content sniff text/plain in dangerous ways. Anyways, if anyone implements, please make sure you cc security on the patch, just in case.

Well its probably safe for css/js, but I would be cautious about the more general case.

Bawolff, do remember that action=raw only supports 3 content types to begin with really. x-wiki, javascript and css. That's the main point I think. if we already only support 3 types, and the content model dictates those 3 types, then why still specify in the url ?

(there's a 4th actually, but not used within WMF i believe).

In T129737#2631988, @TheDJ wrote:

Well its probably safe for css/js, but I would be cautious about the more general case.

Bawolff, do remember that action=raw only supports 3 content types to begin with really. x-wiki, javascript and css. That's the main point I think. if we already only support 3 types, and the content model dictates those 3 types, then why still specify in the url ?

(there's a 4th actually, but not used within WMF i believe).

I meant, if people intended to add new content types, to be careful (i.e. Taking the mime type directly from the default serialization format of the content model). I have no objection to mapping content models to the existing mime types we're using.

I would love to just kill at least ctype, and deprecate action=raw. The interface is dangerous, and under-specified anyway, and it's no longer used by core as far as I know.

Some remarks:

• text/plain may be explicitly excluded from automatic MIME.
• Intersection between content model and MIME is rather sparse.
• Even JSON has no independent MIME type yet, but could be mapped into javascript (at least closer than x-wiki).
• MIME is not supposed to specify details like programming languages, no lua can be expected. JS/ECMA and CSS are an exception since those are processed directly by clients.
• Most content model issues are internal proprietary affairs, not subject to interoperability on MIME level.
• Two formats might become content pages one day, SVG images (today treated as binary media) and application/geo+json for Extension:Kartographer.
• In general, action=raw gives access to source codes in some kind of a formal language, no binaries.

In T129737#2632320, @daniel wrote:

I would love to just kill at least ctype, and deprecate action=raw. The interface is dangerous, and under-specified anyway, and it's no longer used by core as far as I know.

Alas, it is still heavily used in our communities.

In T129737#2634578, @Bawolff wrote:

Alas, it is still heavily used in our communities.

Yea, i guess so. But do many people use ctype?

In T129737#2635083, @daniel wrote:

In T129737#2634578, @Bawolff wrote:

Alas, it is still heavily used in our communities.

Yea, i guess so. But do many people use ctype?

Doing a search of the English Wikipedia (https://en.wikipedia.org/w/index.php?title=Special:Search&profile=advanced&profile=advanced&fulltext=Search&search=ctype&ns2=1) currently says 16,580 results.

In T129737#2635083, @daniel wrote:

In T129737#2634578, @Bawolff wrote:

Alas, it is still heavily used in our communities.

Yea, i guess so. But do many people use ctype?

The answer is, everybody does. It's a required parameter (aside from the legacy gen=js parameter that core used to use). I've never seen usage of action=raw for a JS or CSS page without the ctype parameter. Which is good, because the ctype parameter is part of the canonical action=raw url for those pages.

The canonical url is specified in Title::getCdnUrls() and affects caching. Omitting this query parameter, setting it to something else, or changing the query parameter order - will result in a cache entry that will remain unpurged and stale for upto 30 days.

This canonical url is also consumed by wikibits functions importScript and importStylesheet, which ship with MediaWiki core and are not deprecated. There is no migration path away from user scripts unless we implement something like T36958: User-level gadgets (aka "Gadgets 3.0").

One reason not to do this is that we currently have a legacy use case of loading as text/javascript a page that does not have a title that ends in .js.

So we can consider making the default derived from the content model, but I'm not sure it's worth the trouble trying to enforce it (T113042).

Example:

• Wikipedia:User_scripts/Scripts/foo
• MediaWiki:Common.js/foo