Closed Bug 144221 Opened 22 years ago Closed 14 years ago

Errors saving images to local machine using "Save Link Target As" with persistent connections through a proxy server.

Categories

(Core :: Networking, defect)

1.0 Branch
defect
Not set
major

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: jfarrell, Unassigned)

References

()

Details

(Whiteboard: [closeme 2010-11-15])

Attachments

(3 files)

The first steps of this test ask us to save the 3 images to our local machine.
On OpenVMS Build 20020419, we get the following errors when we attempt this.
When we try and save the first file to local work folder, Mozilla's pop-up
download window tells us that the save has completed 100%, yet when we do a
listing of our working folder, it does not contain the file. Here is some error
output we saw:

CSWS4> @mozilla
Starting mozilla-bin...
Document http://www.mozilla.org/quality/browser/front-end/testcases/ loaded succ
essfully
Document http://www.mozilla.org/quality/browser/front-end/testcases/imaging/ loa
ded successfully
Document http://mozilla.org/quality/browser/front-end/testcases/imaging/img-load
-local/img-load-local-desc.html loaded successfully
Error saving link aStatus = 0x804b0001
CSWS4> @mozilla
Starting mozilla-bin...
Document http://www.mozilla.org/quality/browser/front-end/testcases/ loaded succ
essfully
Document http://www.mozilla.org/quality/browser/front-end/testcases/imaging/ loa
ded successfully
Document http://mozilla.org/quality/browser/front-end/testcases/imaging/img-load
-local/img-load-local-desc.html loaded successfully
Error saving link aStatus = 0x804b0001
ex = TypeError: gDBView has no properties
mailbox://jfarrell@mail.arrayinc.com...skipping, already opened


We were able to view the image by clicking on the link, and then saveing the 
image to our working folder, but "Save link Target as" did not work.

This problem was not reproducable on Linux build 2002041711.
When this issue was brought to Colin Blake's attention, he could not reproduce 
it on his OpenVMS machine either. (He continues to investigate)

After I got the above error and could not download the image, I stopped/started
Mozilla and was able to download the next image.

After getting all 3 files on our machines, I got the following error when I
opened each file, and started to click "Back" to cycle back through the images:

Document file:///sys$common/sysmgr/_mozilla/default/vlpan11.jpg loaded successfu
lly
Document file:///sys$common/sysmgr/_mozilla/default/vlpan12.gif loaded successfu
lly
Document file:///sys$common/sysmgr/_mozilla/default/wall_ni.png loaded successfu
lly
Error loading URL file:///sys$common/sysmgr/_mozilla/default/vlpan12.gif : 80004
005 (NS_ERROR_FAILURE)
Document file:///sys$common/sysmgr/_mozilla/default/vlpan11.jpg loaded successfu
lly
I'm pretty sure this is a VMS problem. Taking (at least for now)...
Assignee: Matti → colin
I've tried and tried but I can not reproduce this on my machine (running OpenVMS 
V7.1-2). I've tried it on your system Jay (CSWS4) and I CAN reproduce it there. 
FWIW - CSWS4 is running V7.3 and CSWS1 V7.2-1.

I've got a 7.2 system here I'm going to try next. Also, this afternoon I should 
have the new CSWB V1.0 kit for you, the one which is based on Mozilla 1.0-RC2. I 
doubt that will fix this problem but its certainly worth a shot.
Status: NEW → ASSIGNED
I still can not produce this on any of my system, but I can see the problem on 
both of your systems, Jay. I wonder if its because you are using a proxy server? 
See bug 142752 for what may be a report of the same problem on Mac.

Jay, here's what I see. When using a proxy server and "save link target as..." 
option, about 75% of the time the file is not saved. After selecting where to 
save the file to, the "saving" window pops up, but there no progress for about 
10-15 seconds, and then its done. But the file is nowhere to be seen. Can you 
confirm if you are also seeing the "no progress for 10-15 seconds", as I'm not 
sure if this is relevant (I am using a remote X display and so I may just be 
seeing network delays).

Jay, you must have an Apache server somewhere. Can you try "save link target 
as" a file from a local Apache server, with proxies turned off. Knowing if 
proxies are involved here will be a big clue.

Re-assigning back to default maintainer as this may not be an OpenVMS-specific 
problem after all, and I'd like some more eyes to see this.
Assignee: colin → Matti
Status: ASSIGNED → NEW
It seems like proxies are involved for sure. If I turn off proxies and access a 
local (company intranet) server, I can "save link target as" as much as I want 
and it works every time. This explains why I could never reproduce it at home 
(hmm, next text is to find a proxy server I can use from home and see if it then 
starts failing; that would really prove that its proxies that are causing this 
problem).

Jay, if you want to try this go to star.zko.dec.com, click on "Technical 
Documents" in the left column, and the select "OpenVMS Internals and Data 
Structures". On the page that displays you will see a PS and PDF file which you 
can right click on and "save link target as".
I couldn't reproduce the problem on my system using my ISP's proxy server, but 
when I switched to Compaq's internal proxy server I could almost reproduce it. 
And this time my browser was Mozilla 1.0-RC2 on Windows98. Here's what I saw.

Using the Compaq proxy server, whenever I "save link target as", the "saving" 
popup appears, the status is "unknown", and it stays like this for 20-30 
seconds. Then the download starts and completes. This is the same pause as I am 
seeing on OpenVMS. The only difference is that on OpenVMS the download doesn't 
occur after the pause. Maybe something is timing out on OpenVMS because some IP 
setting is different?

I need to find out what proxy server Compaq is running as this problem appears 
to be dependant upon the type of proxy server.
I didn't get this entered into Bugzilla before you made your last entry, but
I wanted to add it anyway...
Yes, during our testing, we say the 10-15 second delay as well. At the time,
I assumed that the delay was caused by the size of the images, but the proxy
servers may by involved, we will let you know...
The Compaq proxy server is running Micorsoft-IIS/5.0.

I turned on nsHttp tracing and have logs from both a successful save and an 
unsuccessful one. FWIW, it appears to work the first time when the image isn't 
in the cache, but fails on subsequent attempts. Will post the two logs next. I 
have marked in the failed log where the pause occurred, and note interesting 
message in the log "max hang time exceeded". What does this mean??????
Notice the "max hang time exceeded" message in this log
Changing component to Networking:HTTP since that seems more appropriate.
Component: Browser-General → Networking: HTTP
Reassigning to new component's default owner.
Assignee: Matti → darin
QA Contact: imajes-qa → tever
Something else that sticks out in the failed log:

56310592[349cd80]: reached max request attempts, failing transaction @3fa50d0
yup, that indicates that the server has closed the socket prematurely too many
times such that we choose to simply give up trying to load that particular URL.
 there's not much we can do in that case... though i wonder why the server is
giving up so often.  have you tried downgrading mozilla to HTTP/1.0 and/or have
you tried disabling pipelining or keep-alives?
Attached file Successful recovery
Here's a log from Mozilla on Windows, using the same MS proxy server at Compaq,
where I still see the 20-30 delay, BUT after that the download does complete.
So I have three questions:

1. What is causing the hang? If we can eliminate this then maybe the download
problem will go away?

2. Why can Mozilla 1.0-RC2 on Windows recover after the hang, but Mozilla
1.0-RC2 on OpenVMS not? Is it possible to tell from the logs?

3. After failing to download the file, where's the error message!!!!
> tried disabling pipelining or keep-alives?

Pipelining is not enable. Only Persistent Connections and HTTP 1.1 are enabled.

Jay, can you disabling these (one at a time, they're in prefs, advanced, HTTP 
Network) to see if it works around the problem? Any data point would no doubt be 
very useful here.
When I turn off persistent connections everything works fine. So the problem is 
to do with persistent connections through a proxy server.

Marking this bug as "all platforms" as unless the bug turns out to be in 
Compaq's IP stack, I dont' think its OpenVMS specific.

I think this is serious. Its effectively a data loss bug, since Mozilla tells 
you you've successfully downloaded the file, whereas in fact you haven't. 
There's NO ERROR MESSAGE. Any since most companies require their employees to 
use a company wide proxy server to access the outside world, this problem could 
affect MANY users.
Severity: normal → major
OS: OpenVMS → All
Hardware: Other → All
Bug 140237 may well be a dup. Waiting to hear back from reporter before marking 
so.
mass futuring of untargeted bugs
Target Milestone: --- → Future
Verified that this is still a problem with RC2 release (openVMS build 20020513) 
and with Persistant Connections enabled. When Persistant connection was turned 
off, I could save the images.
I thought we were getting a release note for this. I don't see anything in the
RC3 release notes.
I find this bug to also be very serious for me. Not only does the "Save Link
Target as" produce no file on my machine, but any other command attempt from the
right-click menu fails as well. I cannot save images from any website, even
those that come from sites that I have saved from before.
I wonder, if this is a timing problem,
could this be related to bug 159107 
that has to do with Saving delay and
the downloads.rdf file?
-> default owner
Assignee: darin → nobody
Component: Networking: HTTP → Networking
QA Contact: tever → networking
Target Milestone: Future → ---
several other bugs in this area have been long ago closed
Summary: Errors saving images to local machine using "Save Link Target As" → Errors saving images to local machine using "Save Link Target As" with persistent connections through a proxy server.
Whiteboard: [closeme 2010-11-15]
Closing since now after whiteboard closeme date, code in this area has been reworked in other bugs (per comment 24) and no new reports of this issue in 7 years.

Please reopen/comment with further info, if you still see this issue with Firefox 3.6.13 or later in safe mode:
http://support.mozilla.com/kb/Safe+Mode

If you wish, you can also try to reproduce in Firefox 4 Beta 8 or later:
http://www.mozilla.com/en-US/firefox/all-beta.html
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INCOMPLETE
Version: Trunk → 1.0 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: