Historically, the client would downgrade to API v1.24 when failing
to negotiate as this was the API version from before API-version
negotiation was introduced.
Given that those daemons are EOL and those API versions no longer
supported, we should not fall back to an older API version, and
just continue using the latest / current version.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Make the mocked responses match the API closer;
- Add headers as returned by the daemon's VersionMiddleware
- By default handle "/_ping" requests to allow the client to
perform API-version negotiation as part of tests.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- close idle connections after test
- don't discard failures to write upgrade response
- ignore errors in defer to make the linters happy
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- add early returns for `nil` body, `http.NoBody`, and `json.RawMessage`
- use `http.NoBody` instead of `nil` for empty bodies; it's more clear
on intent.
- use json.Encode instead of json.Encoder.Encode(), as we're marshaling
a single JSON document; this also avoid adding a trailing newline.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This function was setting `text/plain` as default content-type for any
request that had a non-nil body.
However, this would also set the content-type if (e.g.) `http.NoBody` was set,
or if an empty reader was used, which would result in the daemon potentialy
rejecting the request, as it validates request to be using `application/json`;
d9ee22d1ab/daemon/server/httputils/httputils.go (L47-L58)
=== RUN TestCommitInheritsEnv
commit_test.go:30: assertion failed: error is not nil: Error response from daemon: unsupported Content-Type header (text/plain): must be 'application/json'
--- FAIL: TestCommitInheritsEnv (0.02s)
This patch removes setting the default content-type.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
When manually setting the API version to use, automatic API version
negotiation should no longer be performed. Instead of keeping track
of these options individually, we can mark negotiation to have happend
if either the version was set manually, or if API version negotiation
took place.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
While a manual overridden version shouldn't perform automatic version
negotiation, the "ForceNegotiate" option could still be used to (re)
negotiate a version. This allows a client to be configured with an
initial API version, then triggered to perform API-version negotiation.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Environment-variables are expected to override config / defaults, so
make sure that the DOCKER_API_VERSION env-var always takes priority.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Make these options more strict to not allow arbitrary values. Historically,
the `DOCKER_API_VERSION` env-var did not perform any validation as it was
intended for testing-purposes, but given the wider use of this env-var,
we should perform some amount of validation.
Both `WithAPIVersion` and `WithAPIVersionFromEnv` still allow specifying
API versions that are not supported by the client for testing purposes
(e.g. to use API versions beyond `MinAPIVersion` and `MaxAPIVersion`),
but must be well-formed.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Add WithAPIVersion and WithAPIVersionFromEnv to be more clear on
the intent, and to align with other related options and fields.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
this was introduced in c950796596, but
likely due to the "replace" rules not being present, CI tested the
current version of the module instead of the code in the repository.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
While go1.23 still works, it's already EOL, so it may be a better
starting point to use that as minimum version for these modules, as
they're brand new.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
