Comment 15 for bug 1157943

I'm also unconvinced of this patch. It drops the If-Range logic altogether which means that it requests a range without specifying what the mtime of the partial file was. It also does not use If-Modified-Since in this case. So you'd still end up with a file that's partially corrupted if the file changed underneath.

Curl does not seem to have logic to do If-Range properly. So in this case the return code of the HTTP request will indicate if we got the entire file (200 OK) or a partial snippet (206 Partial Content)[1]. 206 will include the range and last-modified date of the current file, which we can check against what we expect. 200 OK should replace the whole file.

(No, I'm not volunteering.)

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html