net/http: WriteHeader called with X-Content-Type-Options:nosniff but no Content-Type

[agnivade]

Please answer these questions before submitting your issue. Thanks!

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

go version go1.11beta1 linux/amd64

Does this issue reproduce with the latest release?

Yes

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

GOARCH="amd64"
GOBIN=""
GOCACHE="/home/agniva/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/agniva/play/go"
GOPROXY=""
GORACE=""
GOROOT="/home/agniva/sdk/go1.11beta1"
GOTMPDIR=""
GOTOOLDIR="/home/agniva/sdk/go1.11beta1/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build285380950=/tmp/go-build -gno-record-gcc-switches"
VGOMODROOT=""

What did you do?

Used 1.11 beta1 to test my web app.

Context: I use the "github.com/unrolled/secure" middleware which injects security headers in my responses. The issue is about the X-Content-Type-Options header.

What did you expect to see?

I expected my Content-Type header to remain unchanged when I use 1.11 beta1.

What did you see instead?

Found that my Content-Type in the response got changed from text/plain; charset=utf-8 to application/octet-stream.

Along with a warning from the app - http: WriteHeader called with X-Content-Type-Options:nosniff but no Content-Type

Repro -

package main

import (
	"log"
	"net/http"
)

func main() {
	http.HandleFunc("/bar", func(w http.ResponseWriter, r *http.Request) {
		w.Header().Set("X-Content-Type-Options", "nosniff")
		// w.Header().Set("Content-Type", "text/plain; charset=utf-8")
		w.WriteHeader(http.StatusCreated)
		w.Write([]byte("OK"))
	})

	log.Fatal(http.ListenAndServe(":8080", nil))

}

This gives Content-Type: text/plain; charset=utf-8 in 1.10.2 and gives Content-Type: application/octet-stream in 1.11beta1.

If you uncomment the line to explicitly set Content-Type, it goes away.

Wondering if this is an intentional change. Because sensitive http clients might break due to this behavior. And if it indeed is intentional, I will have to change all my apps to add this new line 😭

[agnivade]

/cc @bradfitz

[agnivade]

Looks like intentional - #24795.

@bradfitz - What is the expected action here ? Explicitly set content-type ?

[bradfitz]

The X-Content-Type-Options: nosniff header means "I set my Content-Type explicitly and I know it's correct, so please don't sniff it and change it, browsers."

But if you're not setting a content-type, it doesn't make sense to say that the value should not be sniffed by browser.

As such, in Go 1.11 we also don't sniff it, and issue a warning if you issued that header but forgot to set a Content-Type.

So, yes, this is intentional. Although I imagine this does break people who previously trusted Go's content-sniffing but didn't trust the more-aggressive browsers' content sniffing. In that regard this is a regression, but one I'm happy about if this is sufficiently documented in the release notes. https://go-review.googlesource.com/c/go/+/89275 is marked as RELNOTE=yes and I see https://tip.golang.org/doc/go1.11#net/http has a TODO to flesh out the docs on this.

So I think this can be closed, but cc @FiloSottile @mikesamuel if there are other opinions.