Bug 91491

Summary: uses wrong content-size when redirected
Product: [Applications] kget Reporter: Ian <iajava>
Component: generalAssignee: KGet authors <kget>
Status: RESOLVED FIXED    
Severity: normal    
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Ian 2004-10-17 04:00:41 UTC
Version:           0.8.4 (using KDE KDE 3.2.1)
Installed from:    SuSE RPMs
OS:                Linux

Synopsis
--------
Seems KGet wrongly associates the "content-size" from an HTTP "redirect" response with the size of the subsequent response to the actual FTP request to get my file.

Detail
------
Downloaded a file by clicking an HTTP link. File downloads OK, but no progress report shown, nor estimated time of arrival.

KGet's log says _size_ was incorrectly reported, thus downloading till EOF (ie, end of connection), not knowing size in advance.

Note size=366 bytes -- DLed ISO is 630 MB.

KGet's log:

>   03:19:44 : Copy file from: http://www.mirrorservice.org/sites/www.dynebolic.org/dynebolic-1.3.iso
>   03:19:44 : To: file:/vol/moskva/iso/dynebolic-1.3.iso
>   03:19:44 : www.mirrorservice.org contacted. Waiting for reply...
>   03:19:45 : Total size is 366 bytes
>   03:19:45 : File Size checked
>   03:19:45 : Opening connection to host ftp.ukc.mirrorservice.org
>   03:19:45 : Connected to host ftp.ukc.mirrorservice.org
>   03:19:46 : Sending login information
>   03:19:47 : Login OK
>   03:19:48 : The file size does not match!

By the way, the download completes successfully, and MD5 checks OK.

I reported to the site's admin, who so graciously replied thusly:

> >   Foo? Is this an FTP or HTTP transfer?
> 
> Both -- which is probably why your download tool's getting confused!
> 
> We redirect transfers for big files to our FTP server, so the first
> response that it gets is a redirect to ftp://..., hence why it's only
> 366 bytes. I'd guess that your client's comparing that size to the size
> returned by the FTP server for the actual file, seeing that it doesn't
> match, and then giving up.
> 
> Our FTP server does send size information (since last year; I
> implemented it and it worked fine with all the software I tried). I can
> download the dyne:bolic ISO succesfully with wget and curl -L, and both
> parse the size information correctly after the redirect.  Please could
> you let me know which download tool you're using, so I can investigate
> further?

QED?

BTW, I'd look into the source, to try and help, but it's not too easy to find -- the project page at SF (kget.sourceforge.net) smells dead.

Can't find anything relevant in .xsession-errors.

Oddly enough, KGet's log now only shows these two lines:

10:29:52 : Copy file from: http://www.mirrorservice.org/sites/www.dynebolic.org/dynebolic-1.3.iso
10:29:52 : To: file:/vol/moskva/iso/dynebolic-1.3.iso

-- no trace of the log I copied (quoted above) _during_ the download to report the problem. 

The times are wrong, too: download completed successfully 05:19 (took two hours, makes sense). What, another bug? :o|

Any other information? Ask me: iajava(a)yahoo.com.
Comment 1 Ian 2004-10-17 04:09:21 UTC
Uh? Two lines, just near the end, are missing -- I went a page back to the form and the text is there! I submitted it! What, report _another_ bug now?! Arggg! :o)

> -- no trace of the log I copied (quoted above) _during_ the download to 
> report the problem. 
> 
> The times are wrong
...
Comment 2 Lukas Appelhans 2008-05-31 16:30:37 UTC
This is fixed in KGet2..

Lukas