Files
containerd/remotes/docker
Justin Chadwell b4814a29d4 docker: return most relevant error from docker resolution
Previously, we would return the first non-404 error from a host.

This is logical, however, it can result in confusing errors to the
user:

- e.g. we have an HTTP host, and an HTTPS host.

  If the image does not exist, we return "http: server gave HTTP
  response to HTTPS client". This is technically correct, however, the
  user is easily confused - the most relevant error in this case is the
  404 error.

- e.g. we have a broken HTTP host that returns 5XX errors, and a HTTP
  host with authentication.

  On the request for an image, we return the 5XX error directly.
  However, we have a host later on which returned an authentication
  error which is now hidden from the user.

Note: this *can* be resolved by changing the order of hosts passed in,
however this requires 1. knowing ahead of time which hosts are going to
return certain errors and 2. this is often not desirable, we'd prefer
to use HTTPS if it's available, and only then fallback to HTTP.

To resolve this, we assign each possible error during resolution a
"priority" that marks how far through the image resolution process a
host/path combo got. Then we return the error with the highest priority,
which is much more likely to be the most relevant error to the user.

The ranking of priority then is (from lowest to highest):
- Underlying transport errors (TLS, TCP, etc)
- 404 errors
- Other 4XX/5XX errors
- Manifest rejection (due to max size exceeded)

Signed-off-by: Justin Chadwell <me@jedevc.com>
2023-07-26 11:33:50 +01:00
..
2023-05-16 10:12:50 +08:00
2023-05-09 15:07:55 +09:00
2019-10-07 13:38:12 -04:00
2022-07-19 22:46:32 +08:00
2022-04-01 18:17:58 -07:00
2022-01-20 15:16:44 +08:00