From 49356a56651b80a143800474f274118df6fb7d9a Mon Sep 17 00:00:00 2001 From: Brandon Mitchell Date: Sat, 23 Sep 2023 09:13:03 -0400 Subject: [PATCH] Parameters should not be included in Content-Type Signed-off-by: Brandon Mitchell --- spec.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/spec.md b/spec.md index 5f6f1cfa..1897fecb 100644 --- a/spec.md +++ b/spec.md @@ -161,9 +161,11 @@ Throughout this document, `` as a tag MUST be at most 128 characters The client SHOULD include an `Accept` header indicating which manifest content types it supports. In a successful response, the `Content-Type` header will indicate the type of the returned manifest. +The registry SHOULD NOT include parameters on the `Content-Type` header. +The client SHOULD ignore parameters on the `Content-Type` header. The `Content-Type` header SHOULD match what the client [pushed as the manifest's `Content-Type`](#pushing-manifests). 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. -For more information on the use of `Accept` headers and content negotiation, please see [Content Negotiation](./content-negotiation.md). +For more information on the use of `Accept` headers and content negotiation, please see [Content Negotiation](./content-negotiation.md) and [RFC7231](https://www.rfc-editor.org/rfc/rfc7231#section-3.1.1.1). A GET request to an existing manifest URL MUST provide the expected manifest, with a response code that MUST be `200 OK`. A successful response SHOULD contain the digest of the uploaded blob in the header `Docker-Content-Digest`.