On 06/02/21 at 07:44pm, Hung-I Wang wrote:
`curl_retry_next_server` tries to resume a download whenever possible (introduced in 8bf17b2) even if its preceding HTTP request returns an error (with status code >= 400, e.g. 404 when a mirror is only partially synced).
It may result in a corrupted package if the preceding HTTP response with error carries a non-empty body, which is then written to a tempfile as if it is part of the package binary.
By activating `CURLOPT_FAILONERROR`, the tempfile won't be written unless the HTTP response indicates a successful status.
Signed-off-by: Hung-I Wang <whygowe@gmail.com> --- lib/libalpm/dload.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
See 7a5e41925f72d838eaa611427e5ae89b1f57215f: dload: avoid using CURLOPT_FAILONERROR Use of this flag causes connections to be closed on 404s -- a common occurrence when your config sets DatabaseOptional. Handle the error gracefully, so that the connection can be reused. Signed-off-by: Dave Reisner <dreisner@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>