This originally comes from distribution/distribution#2813, and tries to solve the ambiguity of a non-standard content-type which was the root cause of this k8s+containerd+quay regression kubernetes/kubernetes#72863 (comment).

@dmcgowan @vbatts PTAL.

LGTM

This should probably be cross posted, but here we go:

The details of the regression was that Quay added ; charset=utf8 to the Content-Type for manifests. This broke clients. However, for error messages, docker/distribution has always had the charset in addition to application/json. While this isn't technically correct, I'm not sure whether or not removing this field for v1 of OCI will break backcompat with certain clients. The tests for having that charset field are abundant in docker/distribution and I don't know if many of the clients are as diligent about checking for it.

I do agree that we should remove it, if we're confident it won't break existing clients.

LGTM

This was pulled from examples on other apis. Clients that choke on this have a bug anyways, so I’m not sure claiming this is the root cause is quite right. Correct handling on the client will parse out the field and ignore it if it doesn’t apply.

I think most of the code that checks for the charset was written by you, @stevvooe. So if you think it's fine, I'll rubber stamp it.

My experience with working with http headers in Go is that nothing in net/http helps you with the values pulled out of headers (e.g. splitting on ;). Thus, I suspect that docker clients might choke, but this is something we should fix sooner rather than later.

Bump, does this need more green-stamps or can it be merged already?

LGTM