Closed
Bug 408979
Opened 17 years ago
Closed 17 years ago
Downloads are canceled on Exit when using a proxy server (HTTP/1.0)
Categories
(Core :: Networking: HTTP, defect)
Core
Networking: HTTP
Tracking
()
VERIFIED
FIXED
mozilla1.9beta3
People
(Reporter: whimboo, Assigned: whimboo)
References
()
Details
Attachments
(4 files)
(deleted),
text/plain
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
text/plain; charset=UTF-16
|
Details | |
(deleted),
patch
|
Biesinger
:
review+
Biesinger
:
superreview+
damons
:
approval1.9+
|
Details | Diff | Splinter Review |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2007121805 Minefield/3.0b3pre
Today I was wondering why a running or paused download gets canceled on exit of Firefox. At home the resuming is working fine on OS X and also WinXP. So something is going wrong at the company I work for. After thinking about I realized that it could be happen due to our proxy server. So I switched over to our external wlan with direct access. Restarting Firefox and repeating the steps shows me that it is working now. Downloads don't get canceled when exiting Firefox.
We are using several proxies due to load-balancing. All of them have squid/2.5.STABLEx installed.
Reproduce:
1. Entering proxy information within network configuration
2. Running a download from the above URL
3. Exiting Firefox
Now you get a warning that running downloads will be canceled. Instead of canceling the user should be able to resume the download later.
I'm only able to test it under XP but this bug should also happen under different OS.
Flags: blocking-firefox3?
Comment 1•17 years ago
|
||
[2:51am] whimboo: if i don't have a proxy and restart firefox the already downloaded size is shown. let's say 134MB of 650MB
[02:51am] whimboo: And i can resume the download
[02:52am] whimboo: but with a proxy it's always at zero size after a restart
[02:52am] stephend: yeah, I think I know where this is going
[02:52am] stephend: ok
[02:52am] stephend: gotcha now, thanks
[02:52am] stephend: it's the difference between "resume upon restart" and "save as 0 bytes and retry"
Assignee | ||
Comment 2•17 years ago
|
||
I have to correct: it's already set to zero when you select Cancel inside the warning dialog and Firefox is closed.
Comment 3•17 years ago
|
||
If your proxy server doesn't support download resume, I can't see it working (I'm not 100% sure how proxy servers work though...)
Assignee | ||
Comment 4•17 years ago
|
||
The proxy supports resume due to flashget is running fine and can resume paused downloads after restart.
As I can see within moz_downloads we don't get an EntityID for downloads initiated from behind a proxy.
Comment 5•17 years ago
|
||
If we don't get an entity id, we can't resume...
Comment 6•17 years ago
|
||
Is that an HTTP/1.0 server? What's network.http.proxy.version set to?
Assignee | ||
Comment 7•17 years ago
|
||
(In reply to comment #6)
> Is that an HTTP/1.0 server? What's network.http.proxy.version set to?
No, the version is set to 1.1. As Christian pointed out here is the code where the entity id is generated:
http://lxr.mozilla.org/seamonkey/source/netwerk/protocol/http/src/nsHttpChannel.cpp#4696
I'll try to get a log from Live HTTP headers later.
Assignee | ||
Comment 8•17 years ago
|
||
Assignee | ||
Comment 9•17 years ago
|
||
The proxy is really using HTTP/1.0. After talking with biesi on IRC I'll check tomorrow why it shouldn't be possible with HTTP/1.0.
Assignee | ||
Comment 10•17 years ago
|
||
After having a detail view on the log and several documents I also believe it cannot be done with the current implementation. Due to we are using ETag which is only send by HTTP/1.1 servers we cannot build our EntityID.
As long there is no intention to implement an alternative way this should be WONTFIX?
Flags: blocking-firefox3?
OS: Windows XP → All
Hardware: PC → All
Summary: Downloads are canceled on Exit when using a proxy server → Downloads are canceled on Exit when using a proxy server (HTTP/1.0)
Comment 11•17 years ago
|
||
I think that WONTFIX might be the right thing here.
Comment 12•17 years ago
|
||
We don't require ETags. We use them when we have them, but we support resuming even when we don't.
Assignee | ||
Comment 13•17 years ago
|
||
It's really interesting. I made a test with wget similar to the one on bug 401846. Running with the parameter -S shows the response heads of the HTTP requests. The final request still contains an ETag, Last-Modified and Content-Range header. So we still fail due to the HTTP/1.1 limitation.
I'll remove the check for >=HTTP/1.1 for my debug build and will have a look, what happens. For now it looks like we shouldn't resolve this bug as WONTFIX.
Assignee | ||
Updated•17 years ago
|
Attachment #297138 -
Attachment mime type: application/octet-stream → text/plain
Assignee | ||
Comment 14•17 years ago
|
||
Christian, after removal of the HTTP/1.1 check the resuming works fine. It's a good example why we shouldn't exclude all HTTP/1.0 servers. The question is what headers do we really need to have a resumable download?
Assignee | ||
Comment 15•17 years ago
|
||
And further do we have to differentiate between HTTP/1.0 proxies and servers?
Updated•17 years ago
|
Attachment #297138 -
Attachment mime type: text/plain → text/plain; charset=UTF-16
Assignee | ||
Comment 16•17 years ago
|
||
As I have seen proxy servers forward each header. So even if a HTTP/1.0 proxy is in usage it forwards ETag and Last-Modified headers from a HTTP/1.1 server. Against strictly blocking HTTP/1.0 servers we should check if such needed headers exist? Which headers do we really need?
Comment 17•17 years ago
|
||
we don't need any header. but having last-modified and content-length would be good.
Comment 18•17 years ago
|
||
maybe it's ok to just remove the 1.1 check. I'd r+ a patch to do that. the only bad thing that can happen, I think, is that we only detect later that resuming is not possible.
Assignee | ||
Comment 19•17 years ago
|
||
I'll start Tryserver builds later so we could see what happens.
Assignee: nobody → hskupin
Status: NEW → ASSIGNED
Assignee | ||
Updated•17 years ago
|
Component: Download Manager → Networking: HTTP
Product: Firefox → Core
QA Contact: download.manager → networking.http
Assignee | ||
Comment 20•17 years ago
|
||
Tryserver builds are available at:
https://build.mozilla.org/tryserver-builds/2008-01-28_00:36-mozilla@hskupin.info-bug408979/
Assignee | ||
Comment 21•17 years ago
|
||
Finding a real HTTP/1.0 server seems to be not possible. But running the downloads over a HTTP/1.0 proxy works perfectly with my tryserver build.
Mardak or Sdwilsh, when I close Firefox I get a cancel dialog. Is this expected? We have a resumable download here so why that dialog is shown?
If anyone could tell me a HTTP/1.0 server I would be happy. Otherwise as biesi already told we should risk this way.
Assignee | ||
Updated•17 years ago
|
Attachment #299695 -
Flags: review?(cbiesinger)
Comment 22•17 years ago
|
||
(In reply to comment #21)
> Mardak or Sdwilsh, when I close Firefox I get a cancel dialog. Is this
> expected? We have a resumable download here so why that dialog is shown?
See bug 401172 and bug 414161.
Updated•17 years ago
|
Attachment #299695 -
Flags: review?(cbiesinger) → review+
Updated•17 years ago
|
Attachment #299695 -
Flags: superreview+
Assignee | ||
Updated•17 years ago
|
Attachment #299695 -
Flags: approval1.9?
Comment 23•17 years ago
|
||
Comment on attachment 299695 [details] [diff] [review]
Remove HTTP/1.0 check
a1.9+=damons
Attachment #299695 -
Flags: approval1.9? → approval1.9+
Assignee | ||
Updated•17 years ago
|
Keywords: checkin-needed
Comment 24•17 years ago
|
||
Checking in netwerk/protocol/http/src/nsHttpChannel.cpp;
/cvsroot/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp,v <-- nsHttpChannel.cpp
new revision: 1.326; previous revision: 1.325
done
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9beta3
Assignee | ||
Comment 25•17 years ago
|
||
Verified with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008013004 Minefield/3.0b3pre ID:2008013004
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•