Set Content-Type header in registry client ReadFrom#3981
Set Content-Type header in registry client ReadFrom#3981milosgajdos merged 1 commit intodistribution:mainfrom
Conversation
Client ReadFrom doesn't set Content-Type header leading to server side implementor to assume it's application/octet-stream. This commit makes this explicit on the client side. Signed-off-by: Milos Gajdos <[email protected]>
Codecov ReportPatch coverage:
❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more. Additional details and impacted files@@ Coverage Diff @@
## main #3981 +/- ##
=======================================
Coverage 55.91% 55.91%
=======================================
Files 110 110
Lines 11057 11057
=======================================
Hits 6183 6183
Misses 4185 4185
Partials 689 689
☔ View full report in Codecov by Sentry. |
thaJeztah
left a comment
thaJeztah
left a comment
There was a problem hiding this comment.
LGTM
Also wondering;
- should requests set a user-agent?
- very off-topic; I noticed the
Docker-Upload-UUIDheader; is that only for "v1" images? (as v2 would be content-addressable, so more likely to have a digest?)
|
We probably need a backport for this (although I still think it's a bit odd to make this a required header in the spec; not sure if that was intentional). |
No, this header is set on every blob upload (spec mentions them https://github.com/opencontainers/distribution-spec/blob/v1.0.1/spec.md#post-then-put); I think all these legacy headers have |
|
Before we merge, I wanna wait for @corhere 👍 as he was the original reporter. |
5 participants
Client ReadFrom doesn't set Content-Type header leading to server side implementor to assume it's application/octet-stream. This commit makes this explicit on the client side.
Closes #3965