client: always send (empty) body on push#50415
Merged
thaJeztah merged 1 commit intomoby:masterfrom Jul 16, 2025
Merged
Conversation
Before ea29dff, the image create endpoint had a [fallback for very old client versions][1] that would send authentication as body instead of through the `X-Registry-Auth` header. However, the implementation of this fallback did not handle empty bodies, resulting in an `io.EOF` error to be returned when trying to parse the body as JSON. In practice, this problem didn't happen when using the CLI, because even if no authentication was present, `registry.EncodeAuthConfig()` (used by the CLI to set the `X-Registry-Auth` header) would produce an empty JSON document (`{}`), which would be encoded in base64 (`e30=`), so we would never set an empty `X-Registry-Auth` (but other clients may have hit this situation). That behavior was unexpected, because not all registries require authentication, and omitting the `X-Registry-Auth` should be valid. We also want to have more flexibility in authentication (and being able to distinguish unauthenticated requests, so that we can fallback to alternative paths). Unfortunately, we can't change existing daemons, so must account for the faulty fallback. Currently, omitting the `X-Registry-Auth` produces an error, but we can avoid this by unconditionally sending a body, which may be an empty JSON document (`{}`). I explored possible options for this; we can either construct our own empty JSON (`json.RawMessage("{}")`) to be explicit that we're sending empty JSON, but [`encodeBody()`][2] is currently hard-coded to expect JSON requests, and unconditionally calls [`encodeData`][3], which encodes to JSON, so we may as well take advantage of `http.NoBody`, which gets marshaled to an empty JSON document; https://go.dev/play/p/QCw9dJ6LGQu package main import ( "encoding/json" "fmt" "net/http" ) func main() { body, _ := json.Marshal(http.NoBody) fmt.Println(string(body)) } Before this patch, a client omitting `X-Registry-Auth` (and no body) would produce an error; docker pull -q busybox docker tag busybox 127.0.0.1:5001/myimage:latest docker run -d --name registry -p 127.0.0.1:5001:5000 registry:3 docker push 127.0.0.1:5001/myimage:latest Error response from daemon: bad parameters and missing X-Registry-Auth: invalid X-Registry-Auth header: EOF With this patch applied, no error is produced; docker pull -q busybox docker tag busybox 127.0.0.1:5001/myimage:latest docker run -d --name registry -p 127.0.0.1:5001:5000 registry:3 docker push 127.0.0.1:5001/myimage:latest The push refers to repository [127.0.0.1:5001/myimage] 189fdd150837: Pushed latest: digest: sha256:68a0d55a75c935e1101d16ded1c748babb7f96a9af43f7533ba83b87e2508b82 size: 610 [1]: https://github.com/moby/moby/blob/63fcf7d8582bf901b912015db5a590186710b8c6/api/types/registry/authconfig_test.go#L109-L114 [2]: https://github.com/moby/moby/blob/63fcf7d8582bf901b912015db5a590186710b8c6/client/request.go#L67-L87 [3]: https://github.com/moby/moby/blob/63fcf7d8582bf901b912015db5a590186710b8c6/client/request.go#L296-L304 [4]: moby@ea29dff Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
dmcgowan
approved these changes
Jul 15, 2025
This was referenced Jul 23, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Before ea29dff, the image create endpoint had a fallback for very old client versions that would send authentication as body instead of through the
X-Registry-Authheader.However, the implementation of this fallback did not handle empty bodies, resulting in an
io.EOFerror to be returned when trying to parse the body as JSON.In practice, this problem didn't happen when using the CLI, because even if no authentication was present,
registry.EncodeAuthConfig()(used by the CLI to set theX-Registry-Authheader) would produce an empty JSON document ({}), which would be encoded in base64 (e30=), so we would never set an emptyX-Registry-Auth(but other clients may have hit this situation). That behavior was unexpected, because not all registries require authentication, and omitting theX-Registry-Authshould be valid. We also want to have more flexibility in authentication (and being able to distinguish unauthenticated requests, so that we can fallback to alternative paths).Unfortunately, we can't change existing daemons, so must account for the faulty fallback. Currently, omitting the
X-Registry-Authproduces an error, but we can avoid this by unconditionally sending a body, which may be an empty JSON document ({}).I explored possible options for this; we can either construct our own empty JSON (
json.RawMessage("{}")) to be explicit that we're sending empty JSON, butencodeBody()is currently hard-coded to expect JSON requests, and unconditionally callsencodeData, which encodes to JSON, so we may as well take advantage ofhttp.NoBody, which gets marshaled to an empty JSON document;https://go.dev/play/p/QCw9dJ6LGQu
Before this patch, a client omitting
X-Registry-Auth(and no body) would produce an error;With this patch applied, no error is produced;
- What I did
- How I did it
- How to verify it
- Human readable description for the release notes
- A picture of a cute animal (not mandatory but encouraged)