No point in handling them in generic code, and callers that
aren't expecting StatusPartialContent could be confused.
Should not change behavior of GetBlobAt; might in change behavior of
other callers if they unexpectedly received the relevant HTTP status
codes.
This ~mechanically moves the code without much restructuring.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
github.com/docker/distribution is not using the github.com/pkg/errors
wrapping mechanism, and we don't expect them to start.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
just to minimize repetition; the Reponse qualifier applies to
everything in that function, so it doesn't help.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Format the error message use the response body if the original error is returned as client.UnexpectedHTTPResponseError type
Signed-off-by: Qi Wang <qiwan@redhat.com>
E.g.
- Capitalize log messages
- Add a bit more context to the log messages
- Don't commit to specific fallback behavior in the API, only say that it may automatically retry.
- Fix some typos
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Consolidate checking the http-status codes to allow for a more uniform
error handling. Also treat code 429 (too many requests) as a known
error instead of an invalid status code.
When hitting 429, perform an exponential back off starting a 2 seconds
for at most 5 iterations. If the http.Response set the `Retry-Header`
then use the provided value or date to compute the delay until the
next attempt. Note that the maximum delay is 60 seconds.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Miloslav Trmač