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.
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