net/http: successful CONNECT response shouldn't contain Content-Length

[samuong]

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

$ go version
go version go1.13 darwin/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
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/sam/Library/Caches/go-build"
GOENV="/Users/sam/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/sam/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/sam/.brew/opt/go/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/sam/.brew/opt/go/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/sam/go/src/alpaca/go.mod"
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/f4/gg31gkn12gd60772m6wk3wnh0000gn/T/go-build794812018=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Write a successful CONNECT response, using either Response.Write() or httputil.DumpResponse(), like so: https://play.golang.org/p/X5V_Zy51ksS

What did you expect to see?

Just the HTTP status line:

HTTP/1.1 200 OK

What did you see instead?

I see the status line, as well as a Content-Length: 0 header.

HTTP/1.1 200 OK
Content-Length: 0

According to RFC 7231 section 4.3.6:

A server MUST NOT send any Transfer-Encoding or Content-Length header fields in a 2xx (Successful) response to CONNECT.

This causes problems when writing a successful CONNECT response to Safari, which doesn't seem to like the Content-Length header.

[agnivade]

@bradfitz

[samuong]

After looking into this a little more, I've found that I can get around this by explicitly setting resp.ContentLength to -1. It might be nice to have http.ReadResponse() do this automatically when reading a response to a CONNECT request, but setting it myself works fine too.