Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add placeholder for content negotiation #218

Merged
merged 1 commit into from
Dec 10, 2020

Conversation

jdolitsky
Copy link
Member

Related to #212

Copy link
Member

@mikebrow mikebrow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Member

@dmcgowan dmcgowan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@jonjohnsonjr
Copy link
Contributor

jonjohnsonjr commented Dec 9, 2020

@justincormack what do you think about this? I would also like to drop this entirely in favor of manifest list based mechanisms, but I'm reluctant to do so until registries stop downconverting to schema 1.

@justincormack
Copy link

@jonjohnsonjr yeah thats fine. Note that the spec for Accept https://tools.ietf.org/html/rfc7231#section-5.3.2 says

"If the header field is
present in a request and none of the available representations for
the response have a media type that is listed as acceptable, the
origin server can either honor the header field by sending a 406 (Not
Acceptable) response or disregard the header field by treating the
response as if it is not subject to content negotiation."

So it is always fine to serve something the client did not ask for, and
totally ignore Accpet headers. I think we should recommend never sending a 406.

@dmcgowan dmcgowan merged commit 1f2ee9d into opencontainers:master Dec 10, 2020
@jonjohnsonjr
Copy link
Contributor

origin server can either honor the header field by sending a 406 (Not
Acceptable) response or disregard the header field by treating the
response as if it is not subject to content negotiation.

Ooh this is nice. Will probably update GCR's behavior here to match. We might want to call out specifically some suggested behavior in the placeholder section around this? Right now we are returning a 404, which felt correct at the time, but is obviously non-conforming per the rfc. Just ignoring it would be wonderful, but I'm a bit concerned about breaking clients.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants