When no port is specified, allow falling back from 443 to 80 when
http is specified along with a TLS configuration.
Signed-off-by: Derek McGowan <derek@mcg.dev>
Before this, during a call to the docker resolver, we would generate
span wrappers for each HTTPRequest correctly, however, as the docker
resolver reaches out to the docker authorizer, it could create HTTP
requests (for fetching tokens) that would not be wrapped in any span.
This can result in rather confusing traces, e.g. something like:
remotes.docker.resolver.HTTPRequest
HTTP HEAD (fetch index, fails with 401)
HTTP GET (fetch token)
remotes.docker.resolver.HTTPRequest
HTTP HEAD (fetch index)
remotes.docker.resolver.HTTPRequest
HTTP GET (fetch manifest)
By adding a span into the FetchToken, this trace becomes a little easier
to consume:
remotes.docker.resolver.HTTPRequest
HTTP HEAD (fetch index, fails with 401)
remotes.docker.resolver.FetchToken
HTTP GET (fetch token)
remotes.docker.resolver.HTTPRequest
HTTP HEAD (fetch index)
remotes.docker.resolver.HTTPRequest
HTTP GET (fetch manifest)
Signed-off-by: Justin Chadwell <me@jedevc.com>
Schema 1 (`application/vnd.docker.distribution.manifest.v1+prettyjws`) has been
officially deprecated since containerd v1.7 (PR 6884).
We have planned to remove the support for Schema 1 in containerd v2.0, but this
removal may still surprise some users.
So, in containerd v2.0 we will just disable it by default.
The support for Schema 1 can be still enabled by setting an environment variable
`CONTAINERD_ENABLE_DEPRECATED_PULL_SCHEMA_1_IMAGE=1`, however, this workaround
will be completely removed in containerd v2.1.
Schema 2 was introduced in Docker 1.10 (Feb 2016), so most users should
have been already using Schema 2 or OCI.
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
We also need an additional check to avoid setting both the error and
response which can create a race where they can arrive in the receiving
thread in either order.
If we hit an error, we don't need to send the response.
> There is a condition where the registry (unexpectedly, not to spec)
> returns 201 or 204 on the put before the body is fully written. I would
> expect that the http library would issue close and could fall into a
> deadlock here. We could just read respC and call setResponse. In that
> case ErrClosedPipe would get returned and Commit shouldn't be called
> anyway.
Signed-off-by: Justin Chadwell <me@jedevc.com>
If sending two messages from goroutine X:
a <- 1
b <- 2
And receiving them in goroutine Y:
select {
case <- a:
case <- b:
}
Either branch of the select can trigger first - so when we call
.setError and .Close next to each other, we don't know whether the done
channel will close first or the error channel will receive first - so
sometimes, we get an incorrect error message.
We resolve this by not sending both signals - instead, we can have
.setError *imply* .Close, by having the pushWriter call .Close on
itself, after receiving an error.
Signed-off-by: Justin Chadwell <me@jedevc.com>
If we get io.ErrClosedPipe in pushWriter.Write, there are three possible
scenarios:
- The request has failed, we need to attempt a reset, so we can expect a
new pipe incoming on pipeC.
- The request has failed, we don't need to attempt a reset, so we can
expect an incoming error on errC.
- Something else externally has called Close, so we can expect the done
channel to be closed.
This patch ensures that we block for as long as possible (while still
handling each of the above cases, so we avoid hanging), to make sure
that we properly return an appropriate error message each time.
Signed-off-by: Justin Chadwell <me@jedevc.com>
If Close is called externally before a request is attempted, then we
will accidentally attempt to send to a closed channel, causing a panic.
To avoid this, we can check to see if Close has been called, using a
done channel. If this channel is ever done, we drop any incoming errors,
requests or pipes - we don't need them, since we're done.
Signed-off-by: Justin Chadwell <me@jedevc.com>
io.Pipe produces a PipeReader and a PipeWriter - a close on the write
side, causes an error on both the read and write sides, while a close on
the read side causes an error on only the read side. Previously, we
explicitly prohibited closing from the read side.
However, http.Request.Body requires that "calling Close should unblock a
Read waiting for input". Our reader will not do this - calling close
becomes a no-op. This can cause a deadlock because client.Do may never
terminate in some circumstances.
We need the Reader side to close its side of the pipe as well, which it
already does using the go standard library - otherwise, we can hang
forever, writing to a pipe that will never be closed.
Allowing the requester to close the body should be safe - we never reuse
the same reader between requests, as the result of body() will never be
reused by the guarantees of the standard library.
Signed-off-by: Justin Chadwell <me@jedevc.com>
A media type string passed via `WithMediaType()` was not propagated
to a descriptor returned by `FetchByDigest()`.
Follow-up to PR 8744
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
