406203 - download stops abruptly after resume, ends up corrupted but reports as completed

Status: RESOLVED FIXED

(Toolkit :: Downloads API, defect, P3)

Description

[Mike Beltzner [:beltzner, not reading bugmail]]

I paused a download recently (see URL for source), then resumed it a few minutes later. The progress indicator started up, then jumped to the end and showed the download as being complete. When I tried to run the file, it turned out to be corrupted (basically, it was truncated at the point where I paused it).

I suspect that the issue is that we can't resume through SSL sessions, but am not sure.

STR:
1. Go to URL linked in this report
2. Enter whatever information and get to the file download (should be 72.9MB)
3. Pause your download
4. Get a coffee or something
5. Resume your download

Expected:
Download resumes/retries and I get a 72.9MB file, *OR* the pause function isn't available, *OR* some sort of indication that the resume failed and the download is corrupt.

Actual:
Download instantly completes and I get an incomplete file, but it shows up in the download manager as having been completed.

Comment 1

[Shawn Wilsher :sdwilsh]

Biesi - would ssl matter?

Comment 2

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

SSL shouldn't matter.  Do we use ranges to resume?  If so, server capabilities will determine whether "pause" really means "abandon", and I'm not sure we can tell that it'll accept ranges without trying first. :(

Comment 3

[Matthew Middleton (:zzxc)]

I couldn't reproduce this using a SSL connection to my own server.  I created a 20-megabyte file on my HTTPS server and attempted to download and resume it.  It seemed to pass all the tests.  (see full results below)  All these tests were on Linux, so the results may be different for Windows.

After I couldn't reproduce it myself, I tried the blackberry link.  I started the download, then paused it and waited awhile.  To make sure the connection was closed, I did: tcpkill -i eth0 port 443

After the TCP connection was flushed, I attempted to resume the download.

->Result #0: Resume immediately after pausing works.

->Result #1: I waited a long time before resuming, without killing.  The download instantly completed, but there were no http headers captured.  I only got this result once.

->Result #2: After killing the connection too soon, the download terminated with an error message "/home/temp/8100M_PBr4.2.1_rel148_PL2.3.0.77_A4.2.1.94_Rogers(4).exe.part could not be saved, because the source file could not be read."  The file on my server continued to work after this test.

->Result #3: I killed the browser and attempted to restart the download after restoring my session.  The result was that the "resume" button wouldn't work at all - pressing it did nothing.  With the file on my server, the resume worked correctly after the same test.

->Result #4: I tried to get Result #1 again to see if there was any HTTP request issued.  I waited 5 minutes, then resumed the connection.  This time, however, I got the same error message as in Result #2.  Again, the file on my server resumed correctly.


-------------------------------------


Request #1:


POST /Downloads/downloadFile HTTP/1.1

Host: www.blackberry.com

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007113004 Minefield/3.0b2pre

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Cookie: rim.softwaredownloads=VerifyingBugzillaBug%3ABugzillaBug%3An%2Fa+%28testing+bug+in+Firefox%29%3An%2Fa%3An%2Fa%3A%3An%2Fa%3Aother%3APA%3Abugzilla-bug%40dodgeit.com%3A%3A; CP=null*; TLTHID=1B07E56C9F81109F00C3D85A27EB396E; TLTSID=E596227C9F80109F0B7FAE35B7DF7956; JSESSIONID=wma+RoQ2sCXn0AKPbbsjwQ**; BIGipServerExternal_Apps_JRun4HA=2156357130.20480.0000

Content-Type: application/x-www-form-urlencoded

Content-Length: 22

user=8058797&x=50&y=17



Response #1:

HTTP/1.x 200 OK

Date: Fri, 30 Nov 2007 20:16:23 GMT

Server: Apache/2.2.4 (Unix) mod_jk/1.2.20

Set-Cookie: TLTHID=1F2662FE9F81109F00D7D85A27EB396E; path=/; domain=.blackberry.com

X-Powered-By: Servlet 2.4; JBoss-4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)/Tomcat-5.5

content-disposition: attachment; filename="8100M_PBr4.2.1_rel148_PL2.3.0.77_A4.2.1.94_Rogers.exe";

Content-Length: 76453816

Content-Type: application/octet-stream

Keep-Alive: timeout=15, max=86

Connection: Keep-Alive

----------------------------------------------------------

Comment 4

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Do we have test cases for resuming POST?

Comment 5

[Ed Lee :Mardak]

I remember asking biesi about POST resume probably referring to bug 401846. Servers don't support POST resume.

Comment 6

[Shawn Wilsher :sdwilsh]

Is that the situation with this bug?  Can we detect if it's a POST download here?

Comment 7

[Mike Connor [:mconnor]]

I think we should be able to tell that we're downloading the result of a POST and not offer pause in that case.

Comment 8

[Ed Lee :Mardak]

(In reply to comment #0)
> 3. Pause your download
> 4. Get a coffee or something
> 5. Resume your download
Oh. Step 4 is very important for this bug. Because it's a POST download, the pausing functionality reverts to the old Firefox-2 method of just stalling the TCP stream. This isn't related to the new pause/resume code.

Question is.. do we want to remove the old functionality and not support 'fake-pausing'?

Comment 9

[Ed Lee :Mardak]

Whoops. restoring url that I cut/paste to try.

Comment 10

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

(In reply to comment #8)
> Question is.. do we want to remove the old functionality and not support
> 'fake-pausing'?

I vote "yes".  If that option is not available, I will choose "hell, yes".

Comment 11

[Shawn Wilsher :sdwilsh]

(In reply to comment #8)
> Question is.. do we want to remove the old functionality and not support
> 'fake-pausing'?
We need some way to indicate to the user that a download isn't pausable.  Perhaps exposing a property on nsIDownload for it?  Then not display a pause button in the UI?  We need UI feedback here, but I'm in support of removing it.

This should probably be a wanted bug because this issue was existed before Firefox 3 (if I understand it correctly that is).

Comment 12

[Madhava Enros [:madhava]]

I'd be in favour of a disabled pause button rather than no pause button at all.  There's some discussion of similar issues going on in bug 410289.

Comment 13

[Madhava Enros [:madhava]]

A disabled state for the pause button has been added to the list of icons that are being produced for Fx3.

Comment 14

[Shawn Wilsher :sdwilsh]

So, is this bug valid anymore?  The code to disable non-resumable download pausing has landed.  Edward?

Comment 15

[Ed Lee :Mardak]

I haven't tested this download recently, but looking at the HTTP headers, it is a POST request. nsHttpChannel returns NOT_RESUMABLE on GetEntityId for POST so the nsIDownload should be not resumable.

http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp&rev=1.324&mark=4700-4703#4700

I'll check the url download..

Comment 16

[Ed Lee :Mardak]

Yup, the download shows up as "This download cannot be paused". This bug was caused by fake-pausing for too long and TCP breaking the connection.

Fixed by bug 410289.