mime: change JavaScript type to text/javascript

[kjk]

What version of Go are you using (go version)?

$ go version
go version go1.12.5 windows/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\kjk\AppData\Local\go-build
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\Users\kjk\go
set GOPROXY=
set GORACE=
set GOROOT=C:\Go
set GOTMPDIR=
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=C:\Users\kjk\src\apps\offdocs\go.mod
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\kjk\AppData\Local\Temp\go-build840166758=/tmp/go-build -gno-record-gcc-switches

What did you do?

I used http.ServeFile() to serve .js file.

What did you expect to see?

According to https://html.spec.whatwg.org/multipage/scripting.html#scriptingLanguages:javascript-mime-type:

Servers should use text/javascript for JavaScript resources.

What did you see instead?

Currently .js files are served with application/javascript Content-Type.

Note: currently this simply comes from mime.TypeByExtension but I'm not advocating changing the mime type there, as it's a valid JavaScript mime type.

http.ServeFile could special-case mime type for just .js files.

[bradfitz]

Sorry, but we're not going to special case MIME types in net/http so that they differ from the types in the mime package.

So if we did this, we'd need to change the mime package. But it seems that application/javascript is correct. See for instance https://stackoverflow.com/a/4101763

[bradfitz]

Let me know if I'm missing something, though?

[kjk]

I'm not sure we're on the same page wrt. to facts, which, in my opinion, are:

1. RFC 4329 is from 2006 and lists several mime types for JavaScript files, recommending application/javascript

2. The most up-to-date HTML spec (https://html.spec.whatwg.org/multipage/scripting.html#scriptingLanguages:javascript-mime-type) says it should be text/javascript and explicitly calls out NOT using the other MIME types.

3. When it comes to the behavior of ServeFile, HTML spec takes precedence over RFC 4329

As further corroboration https://developers.google.com/web/fundamentals/primers/modules says the same thing:

A note on file extensions
You may have noticed we’re using the .mjs file extension for modules. On the Web, the file extension doesn’t really matter, as long as the file is served with the JavaScript MIME type text/javascript.

From the above it follows that per HTML spec, .js files should be served as text/javascript and that should be the behavior of ServeFile.

As far as a possible remedy, there are several options:

1. Do nothing. I can't say that text/javascript vs. application/javascript matters in practice (i.e. browsers might not care one way or the other). I was just working on a web app and noticed that the behavior of ServeFile differs from what HTML spec says should happen.

2. Change the mime type in mime package. That's the right thing for ServeFile, as per HTML spec, but not the right thing for MIME type as per RFC 4329

3. Special-case Content-Type for .js in ServeFile. That's the right behavior for both specs.

[andybons]

It’s unclear to me what the benefit is to changing this. Things will break (people check mime types in tests all the time) with seemingly little to no benefit (unless I’m missing something).

Will browsers behave differently if you use one over the other? Is there a deprecation event happening soon that will obsolete application/javascript and break things?

What is the tangible benefit of changing this?

@MylesBorins

[agnivade]

@kjk - Any thoughts on Andy's comment ?

[MylesBorins]

Hey All,

As part of standardizing .mjs we are doing an update to the specification for all js related mimes

https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/

TL;DR application/javascript is going to be obsolete and text/javascript will be the recommended mimetype.

 The media type registrations herein are divided into two major
 categories: the sole media type "text/javascript" which is now in
 common usage, and all of the media types that are obsolete.

 For both categories, The ECMAScript media types are to be updated to
 point to a non-vendor specific standard undated specification of
 ECMAScript. In addition, a new file extension of .mjs is to be added
 to the list of file extensions with the restriction that it must
 correspond to the Module grammar of [ECMA-262]. Finally, the [HTML]
 specification is using "text/javascript" as the default media type of
 ECMAScript when preparing script tags; therefore, "text/javascript"
 has been moved intended usage from OBSOLETE to COMMON.

[gopherbot]

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

[agnivade]

Reopening as application/javascript is going to be deprecated. This needs further thought.

[andybons]

Thanks, @agnivade.

@MylesBorins what will break as a result of using application/javascript?

[MylesBorins]

I don’t think we need to worry about things necessarily breaking, but once the spec is updated that mime type will no longer be accurate.

…

On Jul 15, 2019, at 7:29 PM, Andrew Bonventre ***@***.***> wrote: Thanks, @agnivade <https://github.com/agnivade>. @MylesBorins <https://github.com/MylesBorins> what will break as a result of using application/javascript? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#32351?email_source=notifications&email_token=AADZYVZ7ACCLLL4GGCZRY6LP7UB5FA5CNFSM4HRUYVMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ7H2DI#issuecomment-511606029>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADZYVZBI3UKTFYIEWO4SHLP7UB5FANCNFSM4HRUYVMA>.

[andybons]

Got it. Thanks, Myles.

[andybons]

Let’s try this as an early-in-cycle change (altering the mime package to serve text/javascript for .js and .mjs files). https://tip.golang.org/src/mime/type.go#L59 is what we‘d alter.

[andybons]

@MylesBorins what is your opinion on specifying the charset?

Should the mime type for .js and .mjs be text/javascript or text/javascript; charset=utf-8?

I ask because all other text/* mime types in the mime package specify a utf-8 charset.

[gopherbot]

Change https://golang.org/cl/186927 mentions this issue: mime: update type of .js and .mjs files to text/javascript

[MylesBorins]

/cc @bmeck about the charset

[bmeck]

there isn't a recommendation officially. Things should be served as UTF-8 for modules and ignores the MIME parameter if it is present. However, I would exclude this parameter unless it is expected to be enforced, as it does have an affect on Script.

[odeke-em]

/cc @mikesamuel

[gopherbot]

Change https://golang.org/cl/217122 mentions this issue: doc/go1.14: mime: .js files now text/javascript