[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jack Bates
Subject: Re: [Bug-wget] Timestamping and --continue
Date: Wed, 20 Mar 2019 21:31:44 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0

`wget2 --continue` doesn't currently send If-Unmodified-Since either. Should it? To avoid appending modified partial content to incomplete downloads?

I see what you mean about [1], which disables the If-Modified-Since header for incomplete downloads.

[1] https://gitlab.com/gnuwget/wget2/commit/46237b803ce026284fa2751e2977417da506557b#af78bb00d7679958da616bc53f20fa39bb038ff0_3770_3789

On 2019-03-20 1:02 p.m., Tim Rühsen wrote:
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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]