I'm not sure this is correct. If we've already written to a sink, then we can't do a retry because we would end up writing the same data twice. Otherwise we get errors like "error 9 while decompressing xz file". (See 53247d6.)

Seems like CI fails due to e322a16

@edolstra is there any way to reset the sink?

No. But if ranged requests are unavailable, we could discard the first n bytes (where n is the number of bytes previously written to the sink).

Couldn't download raise an exception so that the caller would setup the sink again?

That was what 78fa47a tried to do but it was a lot more complicated.

Actually, we should prevent from connecting the sink until we assert response status code is 2xx

@domenkozar But the status code already is 2xx. The problem is that the transmission of the body gets interrupted.

I'm not so sure, #3278 is 504 and I've seen reports with 526 Invalid SSL Certificate, so I'm a bit puzzled why those are not retried if the body wasn't consumed (and if it was 200, status code wouldn't be able to change?).

Hm, it's possible writeCallback is called with the 5xx body.

Going to continue in #3278