oras-go: `Transfer-Encoding: chunked` responses fail

Hello,

I have been working on a project using the oras client (v2) against a repository hosted on ECR. We are storing an artifact with quite a lot of individual items (431 layers on the final manifest), which seems to cause ECR to chunk the response:

# REPO contains the API of the target repository, private in this case
❯ curl -X GET -I --user "AWS:$(aws ecr get-login-password)" "${REPO}/manifests/latest"
HTTP/1.1 200 OK
Content-Type: application/vnd.oci.image.manifest.v1+json
Docker-Distribution-Api-Version: registry/2.0
Sizes:
Date: Fri, 23 Sep 2022 09:14:00 GMT
Transfer-Encoding: chunked

The library currently explicitly checks for net/http.Response.ContentLength when validating the response, which is for these cases -1 and errors out: GET "${REPO}/manifests/latest": unknown response Content-Length, coming from registry/remote/repository.go

I tried to replicate the behavior with the open source registry image, but even with a manifest with >10000 layers it responds non-chunked, so this might unfortunately be a bit annoying to replicate fully locally.

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 22 (17 by maintainers)

Most upvoted comments

Update: Fix is being deployed WW; will communicate here when that’s complete.

I’ve started working on this as of today and will post some updates in the coming week.

Testing of the fix is in-progress, no issues so far. This should be resolved by mid-week, and then deployed worldwide.

Testing suit is complete. Working on a repro now. The most number of layers I was able to create via a Dockerfile was ~128; beyond that it hits a limit.

fyi we did not create the artifact via Dockerfiles, we used the oras SDK directly.

Yes I can take a look at this; please assign it to me.

@nima Could you take a look since it is an ECR issue?