/cc @bradfitz

I'd rather not. Accepting all garbage in violation of specs leads to madness and insecurity. Postel was a little optimistic. I love how strict HTTP/2 is compared to HTTP/1.x. If we've gone this long with this strictness, I don't think there's a problem. (Or is this new in Go 1.8 compares to Go 1.7?)

At least, I won't consider changing our client until the upstream server is fixed. Is there an open bug for the server already? (Which server is it?)

The server is something related to an RTK GPS system. I don't know anything more about it than that. I suspect it's using CGI scripts that manually generate the headers, since the spacing isn't consistent. Fetching /index.htm gives a 200 OK with correct spacing.

If it works in a browser, but not through my proxy, it's my proxy's fault :-(

You didn't answer my Go 1.7 question.

Go 1.7 gives the same error.

Here's a workaround: set the ReverseProxy.Transport to your own http.Transport and override Transport.DialContext to a wrapper around Dialer.DialContext that wraps its returned Conns in:

type fixHTTPReader struct {
	r io.Reader
}

var httpSpaceSpace = []byte("HTTP/1.0  ")

func (f fixHTTPReader) Read(p []byte) (n int, err error) {
	n, err = f.r.Read(p)
	p = p[:n]
	if bytes.HasPrefix(p, httpSpaceSpace) {
		copy(p[9:], p[10:])
		n--
	}
	return
}

e.g. https://play.golang.org/p/Wsx-dmmkaS

It's not a reverse proxy. It's a forward proxy (github.com/andybalholm/redwood). That's why I don't have any control over the upstream server, or even much information about it. We're exposed to all the brokenness of the whole internet, not just our own data center.

I'm enough of a pragmatist to advocate ignoring extra spaces, but not enough of one to wrap all my upstream connections in a custom reader for the sake of one broken server. So if the relaxed parsing is deemed too Postel, I guess we'll just need to tell our user to figure out a way to bypass the proxy for that particular host.

Sigh. Changes for one server are sad. But sure... if you want to fix it and you include a test, I'll approve it. If browsers accept it, I suppose that's reason enough.

CL https://golang.org/cl/40933 mentions this issue.

This should not be approved. It is one broken server that has tiny market share. If Go changes to be lax here with its large and growing usage then that's a bigger window for more broken servers to creep into existence. Meanwhile, a couple of years down the line, either no one is using this broken GPS or it has a fix because of complaints but Go is stuck violating the standard.

I realise that's a pain for @andybalholm, but the pain shouldn't be shared.

"Protocol designs and implementations should be maximally strict" — https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00

That also describes how HTTP had degraded due to varying implementations and a six-year effort managed to pick through those to create HTTP/1.1; to "restore the ability to create and maintain interoperable implementations". net/http shouldn't chip away at that work.