You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: spec.md
+13-2Lines changed: 13 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -146,7 +146,9 @@ Throughout this document, `<reference>` as a tag MUST be at most 128 characters
146
146
147
147
The client SHOULD include an `Accept` header indicating which manifest content types it supports.
148
148
In a successful response, the `Content-Type` header will indicate the type of the returned manifest.
149
-
For more information on the use of `Accept` headers and content negotiation, please see [Content Negotiation](./content-negotiation.md)
149
+
The `Content-Type` header SHOULD match what the client [pushed as the manifest's `Content-Type`](#pushing-manifests).
150
+
If the manifest has a `mediaType` field, clients SHOULD reject unless the `mediaType` field's value matches the type specified by the `Content-Type` header.
151
+
For more information on the use of `Accept` headers and content negotiation, please see [Content Negotiation](./content-negotiation.md).
150
152
151
153
A GET request to an existing manifest URL MUST provide the expected manifest, with a response code that MUST be `200 OK`.
152
154
A successful response SHOULD contain the digest of the uploaded blob in the header `Docker-Content-Digest`.
@@ -386,11 +388,20 @@ it SHOULD return a `202`. This indicates that the upload session has begun and t
386
388
To push a manifest, perform a `PUT` request to a path in the following format, and with the following headers
0 commit comments