I do not think it is right, it seems to be an abuse of "UNSUPPORTED"

I do not think it is right, it seems to be an abuse of "UNSUPPORTED"

Currently I think UNSUPPORTED will have detailed errors, at least better than InternalServerError.

There is no InternalServerError error for docker registry.

log:

ERROR: failed commit on ref "manifest-sha256:33896528d2ebc8dd157f0f4e6e1a8d28e2580e1fde51ab5655a89158d143a73a": unexpected status from PUT request to https://demo.gitea.com/v2/skydust2b/multiarchtest/manifests/latest: 500 Internal Server Error

I do not think it is right, it seems to be an abuse of "UNSUPPORTED"

Currently I think UNSUPPORTED will have detailed errors, at least better than InternalServerError.

1. These errors shouldn't happen in daily usage, if it happens, end users still could do nothing.
2. It depends on what kind of error you'd like to show to, it is intentionally "not show every internal error to end users" because some errors might contain sensitive server side messages (eg: filesystem path, database IP, etc). If you'd like to show errors to end users, it's better to clearly define what end users would see.

Even you do not care about server-side sensitive information, always returning "unsupported' is definitely an abuse to the docker status code.

1. you are reporting internal errors, it doesn't mean it is not supported
2. if you read docker's document, you could see that "unsupported" is not defined for every API response, if you'd like to strictly follow docker's document, many API should not respond "unsupported".

So I'd like to suggest do not spend more time on this, unless you have a clear plan to use it in some real cases.

I do not think it is right, it seems to be an abuse of "UNSUPPORTED"

Currently I think UNSUPPORTED will have detailed errors, at least better than InternalServerError.

1. These errors shouldn't happen in daily usage, if it happens, end users still could do nothing.
2. It depends on what kind of error you'd like to show to, it is intentionally "not show every internal error to end users" because some errors might contain sensitive server side messages (eg: filesystem path, database IP, etc). If you'd like to show errors to end users, it's better to clearly define what end users would see.

But there was an error message returned before.

Maybe we should desensitize misinformation.

But there was an error message returned before.

No, they don't.

So I'd like to suggest do not spend more time on this, unless you have a clear plan to use it in some real cases.

Again, do not spend time on it unless you have a clear picture about it.