`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/com
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
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 G
On 10/23/18 9:07 AM, Darshit Shah wrote:
> On October 22, 2018 11:49:12 PM UTC, Dave Warren wrote:
>> Currently when a download with timestamping enabled gets interrupted,
>> the timestamp of the resulting file ends up being the current time and
>> when wget is re-executed after connectivity is
On 10/23/18 9:07 AM, Darshit Shah wrote:
> On October 22, 2018 11:49:12 PM UTC, Dave Warren wrote:
>> Currently when a download with timestamping enabled gets interrupted,
>> the timestamp of the resulting file ends up being the current time and
>> when wget is re-executed after connectivity is
On October 22, 2018 11:49:12 PM UTC, Dave Warren wrote:
>Currently when a download with timestamping enabled gets interrupted,
>the timestamp of the resulting file ends up being the current time and
>when wget is re-executed after connectivity is restored the local file
>is then seen as newer a
Currently when a download with timestamping enabled gets interrupted,
the timestamp of the resulting file ends up being the current time and
when wget is re-executed after connectivity is restored the local file
is then seen as newer and skipped.
robocopy handles this a little differently, by
On 2011-03-21 20:39 +0300, Alexander Chernyavsky wrote:
> I'm doing wget http://tex.imm.uran.ru/tex/beameruserguide.pdf -O
> beameruserguide.pdf. Download completes and ls -l shows that file is
> dated as 2005-10-23 20:48. Date command shows Mon Mar 21 20:37:56 MSK
> 2011.
>
> I'm reading in manu
(03/21/2011 10:39 AM), Alexander Chernyavsky wrote:
> Hello,
>
> I'm doing wget http://tex.imm.uran.ru/tex/beameruserguide.pdf -O
> beameruserguide.pdf. Download completes and ls -l shows that file is
> dated as 2005-10-23 20:48. Date command shows Mon Mar 21 20:37:56 MSK
> 2011.
>
> I'm reading
Alexander Chernyavsky wrote:
> Hello,
>
> I'm doing wget http://tex.imm.uran.ru/tex/beameruserguide.pdf -O
> beameruserguide.pdf. Download completes and ls -l shows that file is
> dated as 2005-10-23 20:48. Date command shows Mon Mar 21 20:37:56 MSK
> 2011.
>
> I'm reading in manual:
>> For this re
Hello,
I'm doing wget http://tex.imm.uran.ru/tex/beameruserguide.pdf -O
beameruserguide.pdf. Download completes and ls -l shows that file is
dated as 2005-10-23 20:48. Date command shows Mon Mar 21 20:37:56 MSK
2011.
I'm reading in manual:
>For this reason, -N (for timestamp-checking) is not supp
Caleb,
Caleb Cushing writes:
> I thought it was working because sometimes I seemed to get the files
> updated but the last couple of days no updates came in, so I turned
> continue off and by timestamp check alone it downloaded new files. So
> I guess it must not work all the time :( or somethin
On Sun, Jul 11, 2010 at 9:51 AM, Giuseppe Scrivano wrote:
> Does it work for you?
I thought it was working because sometimes I seemed to get the files
updated but the last couple of days no updates came in, so I turned
continue off and by timestamp check alone it downloaded new files. So
I guess
On Sun, Jul 11, 2010 at 2:52 PM, Caleb Cushing wrote:
> any help in what I need to do or am doing wrong?
>
oh I had to run ./bootstrap which clones a git repo apparently...
guess the docs need to be updated? should ./bootstrap be run when bzr
has updates? or just the first time.
On Sun, Jul 11, 2
Caleb Cushing writes:
> there might be a reason. but if you use timestamp and continue
> together it only seems to utilize continue.
Thanks for your report, I am going to commit this patch. It should fix
the problem you have reported. Does it work for you?
Cheers,
Giuseppe
=== modified fi
GNU Wget 1.12 built on linux-gnu.
there might be a reason. but if you use timestamp and continue
together it only seems to utilize continue.
would seem that it would be better to (obviously pseudo-code)
check timestamp
if timestamp newer on remote
download
else
continue
useful where you
16 matches
Mail list logo
