Re: [Bug-wget] Timestamping and --continue

[Tim Rühsen]

Please look at https://gitlab.com/gnuwget/wget2/issues/410

I believe it's fixed for wget2, but not for wget 1.x. It might be pretty
easy to fix that for wget 1.x, but it's not a priority here (due to
limited time). This might be a good practice to get into the wget 1.x
codebase (and even wget2, if you want to see how we did it there).

Regarding the 416 response... servers seem to behave very differently
here, as they do with if-modified-since.

I tend to disable if-modified-since by default in the next wget 1.x
release if nobody works on a fix.

Regards, Tim

On 20.03.19 19:36, Jack Bates wrote:
> When combined with the --continue option, should --timestamping send an
> If-Unmodified-Since header?
> 
> Currently, if I partially download a file and then run `wget --debug
> --continue --timestamping URL` I get:
> 
>> ---request begin---
>> GET [...] HTTP/1.1
>> If-Modified-Since: Tue, 13 Nov 2018 14:13:29 GMT
>> Range: bytes=1084899556-
>> [...]
>>
>> ---response begin---
>> HTTP/1.1 304 Not Modified
>> [...]
>>
>> ---response end---
>> 304 Not Modified
>> File ‘[...]’ not modified on server. Omitting download.
> 
> and I'm left with the still-incomplete file 😞
> 
> If Wget instead sent If-Unmodified-Since, I'd expect it to resume
> downloading:
> 
>> ---response begin---
>> HTTP/1.1 206 Partial Content
>> [...]
>>
>> ---response end---
>> 206 Partial Content
>> Length: [...], [...] remaining
>> Saving to: ‘[...]’
> 
> If the file was already complete, I'd expect:
> 
>> ---response begin---
>> HTTP/1.1 416 Requested Range Not Satisfiable
>> [...]
>>
>> ---response end---
>> 416 Requested Range Not Satisfiable
>> The file is already fully retrieved; nothing to do.
> 
> And if the file was out of date (complete or otherwise), I'd expect:
> 
>> ---response begin---
>> HTTP/1.1 412 Precondition Failed
>> [...]
>>
>> ---response end---
>> 412 Precondition Failed
>

signature.asc
Description: OpenPGP digital signature