bug-wget
[Top][All Lists]
Advanced

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

Re: [Bug-wget] Bug report: --content-disposition option disables --conti


From: Darshit Shah
Subject: Re: [Bug-wget] Bug report: --content-disposition option disables --continue
Date: Thu, 2 Jan 2014 10:54:02 +0530

I set up a test case and I can replicate this report.

The problem occurs despite the fact that Wget sends a HEAD request first to
parse the filename. Before the second request to the server, Wget does not
check the local file for existence and hence --continue does not have any
effect.

The complete debug output from my test case is below:

Running Test Content Disposition Header
>
> /home/sauron/Programming/wget/src/wget -d -c --content-disposition
>> 127.0.0.1:60715/LOTR
>
> ['/home/sauron/Programming/wget/src/wget', '-d', '-c',
>> '--content-disposition', '127.0.0.1:60715/LOTR']
>
> Setting --continue (continue) to 1
>
> Setting --content-disposition (contentdisposition) to 1
>
> DEBUG output created by Wget 1.14.235-f5626-dirty on linux-gnu.
>
>
>> URI encoding = ‘UTF-8’
>
> --2014-01-02 10:49:42--  http://127.0.0.1:60715/LOTR
>
> Connecting to 127.0.0.1:60715... connected.
>
> Created socket 3.
>
> Releasing 0x0000000002342a90 (new refcount 0).
>
> Deleting unused 0x0000000002342a90.
>
>
>> ---request begin---
>
> HEAD /LOTR HTTP/1.1
>
> User-Agent: Wget/1.14.235-f5626-dirty (linux-gnu)
>
> Accept: */*
>
> Host: 127.0.0.1:60715
>
> Connection: Keep-Alive
>
>
>> ---request end---
>
> HTTP request sent, awaiting response... 127.0.0.1 - - [02/Jan/2014
>> 10:49:42] "HEAD /LOTR HTTP/1.1" 200 -
>
>
>> ---response begin---
>
> HTTP/1.1 200 OK
>
> Server: BaseHTTP/0.6 Python/3.3.3
>
> Date: Thu, 02 Jan 2014 05:19:42 GMT
>
> Content-type: text/plain
>
> Content-Length: 358
>
> Content-Disposition: Attachment; filename=JRR.Tolkein
>
>
>> ---response end---
>
> 200 OK
>
> Parsed filename from Content-Disposition: JRR.Tolkein
>
> Length: 358 [text/plain]
>
> Registered socket 3 for persistent reuse.
>
> --2014-01-02 10:49:42--  http://127.0.0.1:60715/LOTR
>
> Reusing existing connection to 127.0.0.1:60715.
>
> Reusing fd 3.
>
>
>> ---request begin---
>
> GET /LOTR HTTP/1.1
>
> User-Agent: Wget/1.14.235-f5626-dirty (linux-gnu)
>
> Accept: */*
>
> Host: 127.0.0.1:60715
>
> Connection: Keep-Alive
>
>
>> ---request end---
>
> 127.0.0.1 - - [02/Jan/2014 10:49:42] "GET /LOTR HTTP/1.1" 200 -
>
> HTTP request sent, awaiting response...
>
> ---response begin---
>
> HTTP/1.1 200 OK
>
> Server: BaseHTTP/0.6 Python/3.3.3
>
> Date: Thu, 02 Jan 2014 05:19:42 GMT
>
> Content-type: text/plain
>
> Content-Length: 358
>
> Content-Disposition: Attachment; filename=JRR.Tolkein
>
>
>> ---response end---
>
> 200 OK
>
> Length: 358 [text/plain]
>
> Saving to: ‘JRR.Tolkein’
>
>
>> 100% 
>> http://127.0.0.1:60715/LOTR[=======================================================================================>]
>> 358         --.-K/s
>
>
>> Registered socket 3 for persistent reuse.
>
> 2014-01-02 10:49:42 (9.48 KB/s) - ‘JRR.Tolkein’ saved [358/358]
>
>
>> --- Actual
>
> +++ Expected
>
> @@ -88,33 +88,33 @@
>
> Error: Contents of JRR.Tolkein do not match
>
>  h e  -o-l-d- -t-h-a-t- -i-s- -s-t-r-o-n-g- -d-o-e-s- -n-o-t+n+e+w+
>> +t+h+a+t+ +i+s+ +n+o+t+ +s+t+r+o+n+g+ +d+o+e+s   w i
>
>
>
This test was specifically created to fail when Wget does not continue the
download. The test was written in the new Python based test environment and
I'll send a patch with this test soon. (Hopefully with a patch that
corrects the issue)


On Thu, Jan 2, 2014 at 10:09 AM, Yousong Zhou <address@hidden> wrote:

> On 2 January 2014 07:08, Eternal Sorrow <address@hidden> wrote:
> > When I set option "content-disposition" either in command line or in
> > wgetrc, wget refuses to resume download of partially-downloaded file
> > with --continue command line option and strarts download from begining.
>
> I tried the following comand and it worked.
>
>     wget -d -c --quota=1 --content-disposition
> http://greenbytes.de/tech/tc2231/attfnboth.asis
>
> --content-disposition support in wget is experimental. I think many
> cases are not covered.
>
> It will help if the following information can be provided.
>  - Content-Disposition header from the server response.
>  - The filename of the partially downloaded file.
>  - The filename wget tried to write into.
>  - If possible, the minimal command to reproduce.
>
>
>                yousong
>
>


-- 
Thanking You,
Darshit Shah


reply via email to

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