On 3/6/21 12:07 am, Andrew Gregory wrote: > 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 <[email protected]> >> --- >> 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 <[email protected]> > Signed-off-by: Allan McRae <[email protected]> >
Ah - thanks. Will stick with the patch I submitted then. Allan
