That's a real leak in the OptimizeDestinationImageAlreadyExists case,
plus several instances in test code.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
CloudFront returns an unquoted ':' in the boundary, special handle it.
It is needed for partial pulls from quay.io.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Mostly just name changes that should not change behavior,
apart from ioutil.ReadDir -> os.ReadDir avoiding per-item
lstat(2) in some cases.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Following the now-established pattern, introduce private.ImageSource
(with a new SupportsGetBlobAt() method), implement it in
dockerImageSource, and use a wrapped version in c/image/copy.
This gives us private.ImageSource and private.ImageDestination,
to allow for future features.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
The way we actually use this, injecting a progress-reporting
proxy, the PutBlobPartial method doesn't have access to the
full ImageSource; so, differentiate more clearly between
this small interface and an ImageSource.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
The goal is to establish a practical/convenient naming for
internal-only interfaces, now that we are going to start using them
much more frequently.
Design concerns:
- Don't duplicate any public package name (to avoid the
publicTypes/internalTypes names in every single user).
Rules out "types", "image" (as in "image.Destination").
- Don't just use "internal", to keep that around for
very localized private utilities, like oci/internal
"private", as a more or less synonym to "internal", seems
to work acceptably well: we will have types.ImageDestination
and private.ImageDestination.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
ghcr.io converts a multirange request to a 200 response when the
client request too much data.
If the server replies with a 200 status to a partial request then
split the body ignoring any additional content that wasn't requested
by the caller.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
OpenShift returns "application/json; charset=utf-8"; with greatest
respect to the strict need to care about character encoding, we don't
want to get into the business of implementing support for charset
encoding, so just drop that on the floor.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Miloslav Trmač