moby: Pre-golang 1.6 Dockers can't talk to golang 1.6 Docker
When Docker v1.9 (and before) talks to Docker v1.11 (master) via a unix socket the daemon will reject the request with this error:
Error response from daemon: 400 Bad Request: malformed Host header
I believe this is because the HTTP Host header will have a value of: /var/run/docker.sock which isn’t a valid hostname and I believe golang 1.6 is now checking the value in validHostHeader() (in https://golang.org/src/net/http/request.go) and “/” isn’t a valid char.
In Docker v1.11 (master) we now set the HTTP Host header to “”, which is why we don’t see this on master.
I’ve been looking into a way to avoid having golang perform this check but haven’t found a way yet.
Net is that this may force all clients that want to talk to a daemon via a unix docker to be upgraded at the same time as the daemon. Not an ideal UX situation.
The only other option I can think of, and its not great, is to postpone upgrading to golang 1.6 until v1.12 so that we can make v1.11 send a Host header with a value of “” for one release before we turn on this check in the daemon. Then during the v1.12 upgrade process clients can upgrade later then the daemon, as long as they’re at least on v1.11.
Anyway, wanted to open an issue so we could have a discussion and brainstorm on ideas.
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Comments: 33 (31 by maintainers)
Commits related to this issue
- Proof of Concept fix for #20865 Signed-off-by: Darren Shepherd <darren@rancher.com> — committed to ibuildthecloud/docker by ibuildthecloud 8 years ago
- Change from Go1.6 to 1.5 so that Docker1.9 can work with this plugin. More info about the issue at https://github.com/docker/docker/issues/20865 — committed to medallia/convoy by dtx 8 years ago
- Change from Go1.6 to 1.5 so that Docker1.9 can work with this plugin. More info about the issue at https://github.com/docker/docker/issues/20865 — committed to medallia/convoy by dtx 8 years ago
- Ignore invalid host header between go1.6 and old docker clients BenchmarkWithHack-4 50000 37082 ns/op 44.50 MB/s 1920 B/op 30 allocs/op BenchmarkNoHack-4 50000 30829 ns/... — committed to liusdu/moby by coolljt0725 7 years ago
- Merge branch 'malformed-host-header-upstream' into 'IT-1.11.2' Ignore invalid host header between go1.6 and old docker clients to bump go to v1.7.1 ``` BenchmarkWithHack-4 50000 37082 n... — committed to liusdu/moby by hqhq 7 years ago
- Remove hack MalformedHostHeaderOverride This hack was added to fix a compatibility with clients that were built using Go 1.5 and older (added in 3d6f5984f52802fe2f4af0dd2296c9e2e4a1e003) This hack c... — committed to thaJeztah/docker by thaJeztah 5 years ago
- Remove hack MalformedHostHeaderOverride This hack was added to fix a compatibility with clients that were built using Go 1.5 and older (added in 3d6f5984f52802fe2f4af0dd2296c9e2e4a1e003) This hack c... — committed to psftw/docker by thaJeztah 5 years ago
- Remove hack MalformedHostHeaderOverride This hack was added to fix a compatibility with clients that were built using Go 1.5 and older (added in 3d6f5984f52802fe2f4af0dd2296c9e2e4a1e003) This hack c... — committed to burnMyDread/moby by thaJeztah 5 years ago
This is a huge problem. You can’t ignore the fact that a lot of containers bind mount
/var/run/docker.sockand package their own Docker client. When you do this you are force to package the lowest common denominator which for me has been Docker 1.6. Please fix. This really breaks a lot of my stuff and is currently a blocker for me to more thoroughly test Docker 1.11.Weave Net ships a copy of the Docker CLI inside a container so we can call it from a script, so this issue gives us a choice between an image that works for Docker daemon versions 1.6-1.10, or one that works for Docker 1.10 and 1.11 only. Which is not a great user experience.
At first I was thinking that this wasn’t that big of an issue, but after the feedback from the community I’m now leaning towards the belief that we do need to offer some kind of solution - other than “just upgrade”.
One option is to pick-up @ibuildthecloud’s solution ( #21423 ) but make it available via a temporary daemon-side flag/env-var - since its not a lot of code (even after we clean it a little 😉 ) and it can be isolated to be easily removed later.
It wouldn’t take a lot to convince me that we should turn it on by default though, at least for v1.11.
i think its a problem no?
@ibuildthecloud then you’re doing it wrong! haha