Skip to content
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

mime: change JavaScript type to text/javascript #32351

Open
kjk opened this issue May 31, 2019 · 16 comments

Comments

@kjk
Copy link

commented May 31, 2019

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

This comment has been minimized.

Copy link
Member

commented May 31, 2019

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

This comment has been minimized.

Copy link
Member

commented May 31, 2019

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

@kjk

This comment has been minimized.

Copy link
Author

commented May 31, 2019

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.

@bradfitz bradfitz changed the title http.ServeFile should serve .js files with text/javascript, not application/javascript mime: change JavaScript type to text/javascript? May 31, 2019

@andybons

This comment has been minimized.

Copy link
Member

commented May 31, 2019

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

This comment has been minimized.

Copy link
Member

commented Jun 15, 2019

@kjk - Any thoughts on Andy's comment ?

@MylesBorins

This comment has been minimized.

Copy link

commented Jun 17, 2019

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

This comment has been minimized.

Copy link

commented Jul 15, 2019

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.)

@gopherbot gopherbot closed this Jul 15, 2019

@agnivade

This comment has been minimized.

Copy link
Member

commented Jul 15, 2019

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

@agnivade agnivade reopened this Jul 15, 2019

@gopherbot gopherbot closed this Jul 15, 2019

@agnivade agnivade reopened this Jul 15, 2019

@andybons

This comment has been minimized.

Copy link
Member

commented Jul 15, 2019

Thanks, @agnivade.

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

@MylesBorins

This comment has been minimized.

Copy link

commented Jul 17, 2019

@andybons

This comment has been minimized.

Copy link
Member

commented Jul 20, 2019

Got it. Thanks, Myles.

@andybons

This comment has been minimized.

Copy link
Member

commented Jul 21, 2019

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 andybons added this to the 1.14 milestone Jul 21, 2019

@andybons

This comment has been minimized.

Copy link
Member

commented Jul 21, 2019

@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.

@andybons andybons changed the title mime: change JavaScript type to text/javascript? mime: change JavaScript type to text/javascript Jul 21, 2019

@gopherbot

This comment has been minimized.

Copy link

commented Jul 21, 2019

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

@ianlancetaylor ianlancetaylor modified the milestones: 1.14, Go1.14 Jul 22, 2019

@MylesBorins

This comment has been minimized.

Copy link

commented Aug 5, 2019

/cc @bmeck about the charset

@bmeck

This comment has been minimized.

Copy link

commented Aug 5, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.