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.

Biesi - would ssl matter?

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. :(

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

Do we have test cases for resuming POST?

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

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

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

(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'?

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

(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".

(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).

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.

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

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

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

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.