Bug 61383 - *.mjs files should be part of mime application/javascript
Summary: *.mjs files should be part of mime application/javascript
Status: NEW
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_mime (show other bugs)
Version: 2.5-HEAD
Hardware: PC Mac OS X 10.1
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-08-04 16:17 UTC by Bradley Farias
Modified: 2017-08-05 01:42 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bradley Farias 2017-08-04 16:17:32 UTC
Javascript Language body is re-using the MIME for a new parse goal:
https://github.com/tc39/ecma262/issues/322

Used by Node:
https://github.com/nodejs/node-eps/blob/6cc060e94e56859bdb446a0820ef4704731ff0a8/002-es-modules.md
https://github.com/nodejs/node/pull/14369

Already being merged into other tools:
https://github.com/Microsoft/vscode/pull/25747
Comment 1 Jacob Champion 2017-08-04 18:46:26 UTC
Thanks for the heads up! Based on those links, I think this needs to be baked a little bit more before we add it to the official mime.types. You've linked to a draft proposal, and IMO it belongs in httpd after it's standardized and/or in wide use.

In the meantime, server admins are welcome to adjust the mime.types themselves if they need it, so we're not obstructing the rollout.
Comment 2 Bradley Farias 2017-08-04 19:02:53 UTC
What level of support are you needing. If I move the draft to accepted is that enough? Is the merged PR for node needed if not? This issue is being brought up because it was a web compatiblity concern where people cannot use the same files due to lack of MIME support.

Would written statements from browser vendors sway anything?
Comment 3 Jacob Champion 2017-08-04 19:36:38 UTC
(In reply to Bradley Farias from comment #2)
> What level of support are you needing. If I move the draft to accepted is
> that enough?
Now you have me worried/confused. Is that document you linked to binding in any way on the Javascript community? Do you have the power to "accept" it yourself -- and if so, should we use it as proof of standardization? ;D

My point is not that we should meet an arbitrary milestone that I'd be making up on the spot, but that we should feel like the types we add are actually standards (either de facto or otherwise). The stuff you've linked to highlights relatively recent arguments over whether a new MIME suffix should be registered, whether the extension should be .mjs or .jsm, etc.

IMO we should add this to httpd once the world says "yes, *this* is how it is." Which does imply a slight bit of lag time.

> This issue is being
> brought up because it was a web compatiblity concern where people cannot use
> the same files due to lack of MIME support.
Right. Server admins have full power over their mime.types, and if they need their servers to support this, they don't have to wait for us. We're not blocking early adoption as far as I can tell.

> Would written statements from browser vendors sway anything?
Sure, it'd certainly give us a better idea of who intends to make use of this.

Keep in mind that I am not the sole gatekeeper for this. If, at any point, an httpd dev is convinced, then in all likelihood it's going in. I'm just saying that I'm not personally convinced *yet*.
Comment 4 Eric Covener 2017-08-05 01:42:21 UTC
IIUC the bar for httpd to list a type is registration in IANA, but the bar for adding an extension to an existing type is to show it in common use (assuming it's not already in use elsewhere) or present in some standard.

https://www.iana.org/assignments/media-types/media-types.xml

Where we'd normally look to confirm an extension:
https://www.iana.org/assignments/media-types/application/javascript

I didn't find the specific references here too compelling but someone else might be more familiar/comfortable with it.