New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Register some more JavaScript MIME types #2

Closed
annevk opened this Issue Aug 15, 2017 · 37 comments

Comments

4 participants
@annevk

annevk commented Aug 15, 2017

https://html.spec.whatwg.org/#javascript-mime-type has a nice list.

(Although I do wonder if we need a whole RFC for this. It seems HTML Standard should be sufficient as it has been for other things too. In that case you could just do an RFC for that new MIME type.)

@annevk annevk changed the title from Register mome JavaScript MIME types to Register some more JavaScript MIME types Aug 15, 2017

@bmeck

This comment has been minimized.

Show comment
Hide comment
@bmeck

bmeck Aug 15, 2017

Owner

Node etc. don't point to the HTML standard so unless that information gets moved to somewhere else an RFC seems like a sane place.

Owner

bmeck commented Aug 15, 2017

Node etc. don't point to the HTML standard so unless that information gets moved to somewhere else an RFC seems like a sane place.

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Aug 15, 2017

Why can't Node point to HTML?

annevk commented Aug 15, 2017

Why can't Node point to HTML?

@bmeck

This comment has been minimized.

Show comment
Hide comment
@bmeck

bmeck Aug 15, 2017

Owner

Some people see IANA as more authoritative on the matter. Could propose it to Node though.

Owner

bmeck commented Aug 15, 2017

Some people see IANA as more authoritative on the matter. Could propose it to Node though.

@bmeck

This comment has been minimized.

Show comment
Hide comment
@bmeck

bmeck Aug 15, 2017

Owner

I would also note, some MIME databases are scraping IANA. None to my knowledge are scraping the HTML standard.

Owner

bmeck commented Aug 15, 2017

I would also note, some MIME databases are scraping IANA. None to my knowledge are scraping the HTML standard.

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Aug 15, 2017

I'm not saying we shouldn't update IANA, I'm just saying that we don't need an RFC for that.

annevk commented Aug 15, 2017

I'm not saying we shouldn't update IANA, I'm just saying that we don't need an RFC for that.

@bmeck

This comment has been minimized.

Show comment
Hide comment
@bmeck

bmeck Aug 15, 2017

Owner

Is HTML going to be adding .mjs somehow? That seems like it has no place in HTML.

Owner

bmeck commented Aug 15, 2017

Is HTML going to be adding .mjs somehow? That seems like it has no place in HTML.

@adamroach

This comment has been minimized.

Show comment
Hide comment
@adamroach

adamroach Aug 15, 2017

@annevk --

I'm not saying we shouldn't update IANA, I'm just saying that we don't need an RFC for that.

We do. I've had a discussion with the other ART ADs on exactly this topic. Since the original javascript MIME types were registered by an IETF-stream document, any updates to them need to be performed by an IETF-stream document.

If you want to add completely new types, that can be done by any recognized standards organization -- and there's some difference of opinion on the current IESG whether WHATWG qualifies, as the nature of "living standards" is incompatible with the notion of stable references.

But since there's likely going to be updates to text/javascript and application/javascript anyway, it adds very little work to roll any other additions you might think necessary into that document at the same time.

So, in my relatively well-informed opinion, pushing through a very small RFC is actually the easy path here.

adamroach commented Aug 15, 2017

@annevk --

I'm not saying we shouldn't update IANA, I'm just saying that we don't need an RFC for that.

We do. I've had a discussion with the other ART ADs on exactly this topic. Since the original javascript MIME types were registered by an IETF-stream document, any updates to them need to be performed by an IETF-stream document.

If you want to add completely new types, that can be done by any recognized standards organization -- and there's some difference of opinion on the current IESG whether WHATWG qualifies, as the nature of "living standards" is incompatible with the notion of stable references.

But since there's likely going to be updates to text/javascript and application/javascript anyway, it adds very little work to roll any other additions you might think necessary into that document at the same time.

So, in my relatively well-informed opinion, pushing through a very small RFC is actually the easy path here.

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Aug 15, 2017

ART?

I guess as long as this RFC references the HTML Standard for the processing requirements (how to get Unicode out of the bytes comes to mind) it's okay either way.

annevk commented Aug 15, 2017

ART?

I guess as long as this RFC references the HTML Standard for the processing requirements (how to get Unicode out of the bytes comes to mind) it's okay either way.

@bmeck

This comment has been minimized.

Show comment
Hide comment
@bmeck

bmeck Aug 15, 2017

Owner

@annevk the charset parameter is currently defined and has some notes things of interest from https://tools.ietf.org/html/rfc6657#section-3 . Is there something else that needs to be added / a thing we can link to that is not specific to HTML?

Owner

bmeck commented Aug 15, 2017

@annevk the charset parameter is currently defined and has some notes things of interest from https://tools.ietf.org/html/rfc6657#section-3 . Is there something else that needs to be added / a thing we can link to that is not specific to HTML?

@adamroach

This comment has been minimized.

Show comment
Hide comment
@adamroach

adamroach Aug 15, 2017

@annevk --

ART?

Applications and Realtime. The area of the IETF that MIME usage falls under. See https://datatracker.ietf.org/group/art/about/

adamroach commented Aug 15, 2017

@annevk --

ART?

Applications and Realtime. The area of the IETF that MIME usage falls under. See https://datatracker.ietf.org/group/art/about/

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Aug 16, 2017

@bmeck I think you need to link to HTML since that defines the defaults, which encodings are valid, etc.

annevk commented Aug 16, 2017

@bmeck I think you need to link to HTML since that defines the defaults, which encodings are valid, etc.

@adamroach

This comment has been minimized.

Show comment
Hide comment
@adamroach

adamroach Aug 16, 2017

@annevk -- I think you're conflating a couple of things here - there's ECMAScript as a syntax; and then there's how HTML uses that syntax. This is dealing with the former, while the HTML spec will deal with the latter.

For example, I wouldn't expect the HTML spec to bear on how node.js interacts with my filesystem when it uses a .js or .jsm file; that whole interaction is 100% HTML-free.

Put another way: I wouldn't expect to have to reference any W3C documents when registering MIME types for GIF, JPEG, or OGG formats, even though they do end up being used in HTML contexts. Why is JavaScript different?

adamroach commented Aug 16, 2017

@annevk -- I think you're conflating a couple of things here - there's ECMAScript as a syntax; and then there's how HTML uses that syntax. This is dealing with the former, while the HTML spec will deal with the latter.

For example, I wouldn't expect the HTML spec to bear on how node.js interacts with my filesystem when it uses a .js or .jsm file; that whole interaction is 100% HTML-free.

Put another way: I wouldn't expect to have to reference any W3C documents when registering MIME types for GIF, JPEG, or OGG formats, even though they do end up being used in HTML contexts. Why is JavaScript different?

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Aug 16, 2017

@adamroach because JavaScript expects a stream of scalar values as input to its parser, not a byte sequence.

annevk commented Aug 16, 2017

@adamroach because JavaScript expects a stream of scalar values as input to its parser, not a byte sequence.

@adamroach

This comment has been minimized.

Show comment
Hide comment
@adamroach

adamroach Aug 16, 2017

@annevk -- Sure. In the general sense, that's what the MIME charset attribute communicates: how to map from a byte sequence to characters. For the domain that the HTML spec applies to, it has its own rules; but they're not applicable across all uses of ECMAScript.

adamroach commented Aug 16, 2017

@annevk -- Sure. In the general sense, that's what the MIME charset attribute communicates: how to map from a byte sequence to characters. For the domain that the HTML spec applies to, it has its own rules; but they're not applicable across all uses of ECMAScript.

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Aug 16, 2017

Okay, then you'll need to say that it's host-dependent, just like ECMAScript defers a bunch of logic to hosts. You can't say it's charset because that's wrong.

annevk commented Aug 16, 2017

Okay, then you'll need to say that it's host-dependent, just like ECMAScript defers a bunch of logic to hosts. You can't say it's charset because that's wrong.

@bmeck

This comment has been minimized.

Show comment
Hide comment
@bmeck

bmeck Aug 16, 2017

Owner

@annevk we can state that the charset may be ignored like in https://tools.ietf.org/html/rfc6657#section-3 ?

HTML doesn't seem to deal w/ charset from MIME that I can tell. I can send invalid charsets and it still won't seem to affect things.

Owner

bmeck commented Aug 16, 2017

@annevk we can state that the charset may be ignored like in https://tools.ietf.org/html/rfc6657#section-3 ?

HTML doesn't seem to deal w/ charset from MIME that I can tell. I can send invalid charsets and it still won't seem to affect things.

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Aug 16, 2017

It's not ignored, but an invalid value doesn't mean the script won't be parsed either. (Also, I would expect Node to want the same behavior as HTML does to some extent here. E.g., a BOM trumping any encoding declaration.)

annevk commented Aug 16, 2017

It's not ignored, but an invalid value doesn't mean the script won't be parsed either. (Also, I would expect Node to want the same behavior as HTML does to some extent here. E.g., a BOM trumping any encoding declaration.)

@bmeck

This comment has been minimized.

Show comment
Hide comment
@bmeck

bmeck Aug 16, 2017

Owner

@annevk this is a good point; I would like to see if considerations for #!, BOM, and other preprocessing exceptions exist already. Searching around RFCs didn't bring up anything but hard to search for those concepts by term.

Owner

bmeck commented Aug 16, 2017

@annevk this is a good point; I would like to see if considerations for #!, BOM, and other preprocessing exceptions exist already. Searching around RFCs didn't bring up anything but hard to search for those concepts by term.

@bmeck

This comment has been minimized.

Show comment
Hide comment
@bmeck

bmeck Aug 16, 2017

Owner

BOM appears to be covered through https://tc39.github.io/ecma262/#sec-unicode-format-control-characters since it just states that it is treated as whitespace and does not affect the Source Text on ECMAScript spec. I don't see anything for #! in any of the https://iana.org/assignments/media-types i've been reading.

Owner

bmeck commented Aug 16, 2017

BOM appears to be covered through https://tc39.github.io/ecma262/#sec-unicode-format-control-characters since it just states that it is treated as whitespace and does not affect the Source Text on ECMAScript spec. I don't see anything for #! in any of the https://iana.org/assignments/media-types i've been reading.

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Aug 16, 2017

Yeah, except it's not treated as whitespace (it's in fact removed before being handed to ECMAScript in theory though I suspect that can't be observed one way or another).

annevk commented Aug 16, 2017

Yeah, except it's not treated as whitespace (it's in fact removed before being handed to ECMAScript in theory though I suspect that can't be observed one way or another).

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Aug 16, 2017

See https://encoding.spec.whatwg.org/#decode for the algorithm that's eventually invoked to obtain the Source Text once there's an encoding (either through an attribute or from the charset parameter).

annevk commented Aug 16, 2017

See https://encoding.spec.whatwg.org/#decode for the algorithm that's eventually invoked to obtain the Source Text once there's an encoding (either through an attribute or from the charset parameter).

@bmeck

This comment has been minimized.

Show comment
Hide comment
@bmeck

bmeck Aug 16, 2017

Owner

stripping certainly changes character indexes in stack traces. It is observable in that sense. Still grepping around to see if those preprocessor considerations exist in other RFCs. I feel like they should...

Owner

bmeck commented Aug 16, 2017

stripping certainly changes character indexes in stack traces. It is observable in that sense. Still grepping around to see if those preprocessor considerations exist in other RFCs. I feel like they should...

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Aug 16, 2017

Apparently the old JavaScript RFC had something very similar about BOMs too, but it did it too late: https://tools.ietf.org/html/rfc4329#section-4.2. (And it didn't cover script element / document encoding defaulting.)

annevk commented Aug 16, 2017

Apparently the old JavaScript RFC had something very similar about BOMs too, but it did it too late: https://tools.ietf.org/html/rfc4329#section-4.2. (And it didn't cover script element / document encoding defaulting.)

@bmeck

This comment has been minimized.

Show comment
Hide comment
@bmeck

bmeck Oct 4, 2017

Owner

@annevk I have fixed the encoding to be host dependent. I am hesitant to register the other media types since they are still obsolete. Is this ok to close?

Owner

bmeck commented Oct 4, 2017

@annevk I have fixed the encoding to be host dependent. I am hesitant to register the other media types since they are still obsolete. Is this ok to close?

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Oct 4, 2017

What do you mean with obsolete?

Note also that previous RFC registered text/javascript as obsolete, whereas the HTML Standard recommends using that MIME type exclusively.

annevk commented Oct 4, 2017

What do you mean with obsolete?

Note also that previous RFC registered text/javascript as obsolete, whereas the HTML Standard recommends using that MIME type exclusively.

@bmeck

This comment has been minimized.

Show comment
Hide comment
@bmeck

bmeck Oct 4, 2017

Owner

@annevk text/javascript is changed to COMMON in this. That RFC should not be the source of discussing text/javascript when its registration is being replaced.

I mean obsolete as in not even in the IANA. Though I see that application/ecmascript is present and should probably be added as well.

Owner

bmeck commented Oct 4, 2017

@annevk text/javascript is changed to COMMON in this. That RFC should not be the source of discussing text/javascript when its registration is being replaced.

I mean obsolete as in not even in the IANA. Though I see that application/ecmascript is present and should probably be added as well.

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Oct 4, 2017

Not in IANA doesn't mean they're obsolete though. It just means nobody bothered to register them. And since the way to get them easily registered is to publish an RFC, the idea was to do that here. See also comments by @adamroach above.

annevk commented Oct 4, 2017

Not in IANA doesn't mean they're obsolete though. It just means nobody bothered to register them. And since the way to get them easily registered is to publish an RFC, the idea was to do that here. See also comments by @adamroach above.

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Oct 4, 2017

Whether we then classify them as obsolete or not, I don't care strongly. I'd probably recommend against anything that isn't text/javascript.

annevk commented Oct 4, 2017

Whether we then classify them as obsolete or not, I don't care strongly. I'd probably recommend against anything that isn't text/javascript.

@bmeck

This comment has been minimized.

Show comment
Hide comment
@bmeck

bmeck Oct 4, 2017

Owner

@annevk added in 9f52db7

Owner

bmeck commented Oct 4, 2017

@annevk added in 9f52db7

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Oct 4, 2017

And e9e47ca it seems. That commit on its own was rather confusing.

annevk commented Oct 4, 2017

And e9e47ca it seems. That commit on its own was rather confusing.

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Oct 4, 2017

It seems like you listed all as COMMON, was that intended?

annevk commented Oct 4, 2017

It seems like you listed all as COMMON, was that intended?

@bmeck

This comment has been minimized.

Show comment
Hide comment
@bmeck

bmeck Oct 4, 2017

Owner

@annevk yes, it at least gives consistent messaging with WHATWG list.

Owner

bmeck commented Oct 4, 2017

@annevk yes, it at least gives consistent messaging with WHATWG list.

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Oct 4, 2017

In https://html.spec.whatwg.org/#mime-types-2 we list everything but text/javascript as legacy type. But indeed we haven't really made any recommendations with respect to the server elsewhere. I think that's just a bug and we meant to encourage text/javascript everywhere.

annevk commented Oct 4, 2017

In https://html.spec.whatwg.org/#mime-types-2 we list everything but text/javascript as legacy type. But indeed we haven't really made any recommendations with respect to the server elsewhere. I think that's just a bug and we meant to encourage text/javascript everywhere.

@bmeck

This comment has been minimized.

Show comment
Hide comment
@bmeck

bmeck Oct 4, 2017

Owner

@annevk moved all except text/javascript to OBSOLETE in 063e5c6

Owner

bmeck commented Oct 4, 2017

@annevk moved all except text/javascript to OBSOLETE in 063e5c6

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Oct 4, 2017

Thanks @bmeck. I think this can be closed then, but I'll leave that up to you. I'll make sure we have some follow-up on the HTML Standard side to actually recommend text/javascript for resources.

annevk commented Oct 4, 2017

Thanks @bmeck. I think this can be closed then, but I'll leave that up to you. I'll make sure we have some follow-up on the HTML Standard side to actually recommend text/javascript for resources.

@bmeck bmeck closed this Oct 4, 2017

annevk added a commit to whatwg/html that referenced this issue Oct 4, 2017

annevk added a commit to whatwg/html that referenced this issue Oct 5, 2017

alrra added a commit to webhintio/hint that referenced this issue Oct 6, 2017

@jabcreations

This comment has been minimized.

Show comment
Hide comment
@jabcreations

jabcreations Oct 6, 2017

There is no such thing as "text/javascript". The only anyone would so that specific random garble of text is because Internet Explorer 6 does not comprehend application/javascript.

Why is this even a thing? Why do there need to be more mimes? This seems like a complete waste of time and resources. Multiple mime types for the exact same thing (JavaScript) will only serve to confuse less experienced developers and only serve to undermine technology as a whole. If you break the standards we professionals will begin to ignore more than just the corrupted parts of them.

jabcreations commented Oct 6, 2017

There is no such thing as "text/javascript". The only anyone would so that specific random garble of text is because Internet Explorer 6 does not comprehend application/javascript.

Why is this even a thing? Why do there need to be more mimes? This seems like a complete waste of time and resources. Multiple mime types for the exact same thing (JavaScript) will only serve to confuse less experienced developers and only serve to undermine technology as a whole. If you break the standards we professionals will begin to ignore more than just the corrupted parts of them.

@bmeck

This comment has been minimized.

Show comment
Hide comment
@bmeck

bmeck Oct 6, 2017

Owner

@jabcreations for quite some time HTML spec has used text/javascript when preparing a script. I am not sure what

There is no such thing as "text/javascript".

means given that.

The existing MIMEs are marked as obsolete, they are not being removed. The additional MIMEs are added to reflect the reality of what is acceptable as a JS MIME.

Owner

bmeck commented Oct 6, 2017

@jabcreations for quite some time HTML spec has used text/javascript when preparing a script. I am not sure what

There is no such thing as "text/javascript".

means given that.

The existing MIMEs are marked as obsolete, they are not being removed. The additional MIMEs are added to reflect the reality of what is acceptable as a JS MIME.

RehanSaeed added a commit to RehanSaeed/StaticFiles that referenced this issue Oct 30, 2017

text/javascript is now the "correct" mime type
I noticed this change when I got a warning while trying out [Sonar](webhintio/hint#568). Apparently the standards bodies have changed their minds:

- whatwg/html#3096
- bmeck/I-D#2

@snuggs snuggs referenced this issue Jun 9, 2018

Open

GET Accept: text/javascript #174

7 of 16 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment