Checks that are too narrow are not compliant with the V2 specification. All 2xx and 3xx responses should generally be treated as successful. The body should only be decoded as an error body on 4xx and 5xx responses. These narrow checks will prevent future protocol evolution if a different error code is used in particular cases. It will also cause issues with proxies that may rewrite responses based on certain behavior.

A salient example may be returning a 304 instead of a 202 when putting a manifest. The method should only be concerned that the content safely made it, with a success http code. Whether it is a 202 or 304 or 307 (won't actually be propagated with go http client) doesn't really matter.

This does not apply when the method requires data to be returned but the error must be handled differently.

Please see the following for more information: https://github.com/docker/distribution/blob/master/doc/SPEC.md#errors-1