docker pull is more restrictive now w.r.t. MediaTypes

[duglin]

Using docker v1.14.0 (master) I see this:

$ docker pull gcr.io/kubernetes-helm/tiller:v2.1.3
Error response from daemon: target is unknown

After some digging, this error is coming from:
https://github.com/docker/docker/blob/master/distribution/pull_v2.go#L366

		if !allowedMediatype {
			configClass := mediaTypeClasses[m.Manifest.Config.MediaType]
			if configClass == "" {
				configClass = "unknown"
			}
			return false, fmt.Errorf("target is %s", configClass)
		}

And the MediaType being returned from gcr.io is "text/html".

I believe in older version of this code we never checked the mediaType to see if its valid and that's why this works on older Dockers. I'm in talks with the gcr.io guys to see if they can fix their code so that they return a valid value, but in the meantime we may want to consider being more forgiving in our code to allow for non-compliant registries.

Or, in @stevvooe's words:
we should probably have a set of media types that revert to some default (like schema2)

[justincormack]

I presume this was changed when v2 plugins (with a different media type) were introduced.

[duglin]

if I did my git commands right, I think the PR that introduced it was: #29339

[waghpooja]

docker versions 1.10 onwards and < 1.11.1 pushed schema2 manifests with config text/html as per #22378
So this change in 1.14.x will cause pull issues for images pushed with those versions.

[dmcgowan]

It certainly was my intent to handle former bugs and treat them as the known image type. We knew about this https://github.com/docker/docker/pull/29339/files#diff-8448734ad4bcad711a430d27d303ac16R26 and I am not against adding text/html with a comment linking to #22378. I stand by making the check more restrictive though as it allows us expand the set of media types without having to worry about breaking older clients which may treat them as an image with unknown results.

[hjacobs]

This strict check also breaks our Pier One Docker registry: zalando-stups/pierone#130

We will probably do a quick hack to return whatever the Docker client now expects 😞

[dmcgowan]

@hjacobs do you have a sample manifest from one of these registries so we can see which media type it has in the manifests? If you don't want to share the whole manifest, just the media type of the config will do.

[hjacobs]

@dmcgowan our Open Source registry is open, so you can see yourself: https://registry.opensource.zalan.do/v2/stups/openjdk/manifests/8-54

[hjacobs]

It still works/worked with rc4 btw, so I downgraded now: sudo apt-get install docker-engine=1.13.0~rc4-0~ubuntu-xenial

[uggedal]

This issue is present in 1.13.0 final as well.

[hjacobs]

We fixed it (workaround!) in our Pier One Docker registry by rewriting the manifest on the fly: zalando-stups/pierone#131

[stevvooe]

We fixed it (workaround!) in our Pier One Docker registry by rewriting the manifest on the fly: zalando-stups/pierone#131

This might break content verification. Are you just setting the content type or are you tampering with the content? If you are tampering with the content, fetch by digest will break.

[thaJeztah]

This is fixed by #30262, which will be in 1.13.1, so let me go ahead and close this