ssl via tunneling proxy horribly slow, fails to load completely, displays junk



Core Graveyard
Security: UI
17 years ago
9 months ago


(Reporter: KenW, Assigned: David P. Drinan)



1.0 Branch
Windows 95

Firefox Tracking Flags

(Not tracked)




17 years ago
When I try to access with build 2001022209 via a 
tunneling proxy (Raptor), the page never finishes loading and the top of the 
browser window displays what looks like the HTTP reply headers:

"Server: Netscape-Enterprise/3.6 SP2 Date: Mon, 26 Feb 2001 17:56:36 GMT 
Content-type: text/html Connection: close"

At least it doesn't crash the app or my PC anymore.

Comment 1

17 years ago
sending to networking, CC'ing dougt
Component: Browser-General → Networking

Comment 2

17 years ago
ssl proxy problem.   Darin, you know anything about this?

Comment 3

17 years ago
I'll look into this.
Assignee: asa → darin

Comment 4

17 years ago
this could be remedied in recent builds. Isn't this the kind of problem we were
seeing in bug 31174 before the dougt branch landed?

Comment 5

17 years ago
I downloaded build 2001022605 (via build bar at Mozillazine) and the problem 
still exists. One small difference, after trying to download for a while, PSM crashes but the browser continues to 
work and I can browser non-secure pages.

Comment 6

17 years ago
I think the PSM folks should look into this.  Regardless of what mozilla does,
PSM shouldn't be crashing.
Assignee: darin → mstoltz
Component: Networking → Security: General
QA Contact: doronr → ckritzer
I agree. However, I am not the PSM folks. Reassigning.
Assignee: mstoltz → ddrinan
Component: Security: General → Security: Crypto
QA Contact: ckritzer → junruh

Comment 8

17 years ago
More info: TLS is turned off as per the comments in bug 31174. When the PSM
crashes, I get the little Windows alert box containing the following debug info:

PSM caused an invalid page fault in
module MSVCRT.DLL at 0137:7800d560.
EAX=00700078 CS=0137 EIP=7800d560 EFLGS=00010246
EBX=0080000c SS=013f ESP=00effe4c EBP=00effe6c
ECX=30000000 DS=013f ESI=ffffffff FS=0dd7
EDX=008caa7c ES=013f EDI=008c88c0 GS=0f6e
Bytes at CS:EIP:
89 79 08 0f 84 15 01 00 00 8b 4d f4 8b 7c f1 04 
Stack dump:
0000000c 00000010 00000000 816d7560 00000020 00703018 00000000 00000017 00effeac
7800ce77 0080000c 008caa80 00000000 008af4c0 7800ef03 7802e248 

However, the fact that PSM eventually crashed may or may not be related to the
original problem.

Comment 9

17 years ago
cc'ing PSM folks to get some help understanding this crash, etc.
I'm not at all familiar with the psm 1.x code, so I probably won't be much help.

Comment 11

17 years ago
KenW do you have the Talkback ID from the crash?

Comment 12

17 years ago
Is anyone still seeing this in recent builds?  Much has changed at the socket
Keywords: qawanted

Comment 13

17 years ago
Keyser Sosez: The crash didn't seem to generate a "talkback" (even if it 
did, talkback doesn't seem to work through our corporate firewall).

Darin Fisher: I downloaded the March 12th nightly via the link at Mozillazine 
and tried it again. This time, hitting the stop button doesn't crash PSM. 
However, the original bug report stands. A few slight behavioural changes: the 
HTML loads much faster but still has HTTP header garbage at the top, the images 
don't seem to load at all (I haven't waited more than a couple of minutes). I 
have tried the same build from my home PC, which connects directly to the 
Internet, and it works fine with exactly the same URL.

Comment 14

17 years ago
Thanks for the feedback!  I'll be looking into this shortly.

Comment 15

17 years ago
I suspect there might be some problems (similar in nature to bug 31174) on the
part of HTTP.  Though I'm not really sure.

Comment 16

17 years ago
Setting to new and qawanted.
Ever confirmed: true


17 years ago
Keywords: perf


16 years ago
Component: Security: Crypto → Client Library
Product: Browser → PSM
Version: other → 2.0

Comment 17

16 years ago
Is this still a problem with the most recent builds (using PSM2)?
Target Milestone: --- → 2.0

Comment 18

16 years ago
I just tried out a build from April 27 (see below) and ran into a (new?) problem 
with the proxy authentication. When accessing an internal secure site, Moz is 
pretty snappy. Here's a blow by blow description of what happens when I try to 
go outside the firewall:

1. Try (http, not https). Get prompted for user id and pw, page 
loads fine.

2. Try Get prompted again for user id and pw (should 
not happen). Error page from firewall loads. This is the error page that gets 
displayed if I try to access the firewall itself as a web site. The firewall is 
an old Raptor firewall that uses the CONNECT protocol to establish an SSL 

Of note: We are on a very secure internal network. There is no access to the 
outside except through the firewall; the internal DNS does not resolve any 
external addresses. Would it be possible for a group of engineers to set up and 
work within a special network zone that mimics this setup, which is pretty 
standard for security conscious/paranoid corporations? I think this would be a 
big help in identifying the source of the problem.

Overall, the browser seems to be rounding in to pretty good shape, which makes 
this particular bug very frustrating!

Version: Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.8.1+) Gecko/20010427

Comment 19

16 years ago
A bug in CONNECT was fixed over the weekend.  Please try a 4/30 or later build.

Comment 20

16 years ago
Okay, tried out the latest win32 nightly (2001043004) and we're partially back 
to the original problem. The difference is that the page loads quite fast but 
the images are still missing and there is still HTTP header junk displayed at 
the top of the page. We also still have the problem with the browser asking for 
the firewall password a second time.

From trying to look at the images (using the very nice 'page info' interface), 
it looks like the HTTP header junk is also getting mixed up with the image 
content, which would explain why they aren't being displayed.

Comment 21

16 years ago
Possible dumb question:

Is there any reason people think this is a PSM and not a Necko problems?

This is important becase if this is Necko related, it needs to be nominated and
targeted for mozilla 0.9.1.

Asa had mentioned to me that m0.8.1 would ship with serious performance problems
in necko, regarding HTTPS via SSL proxy.

Comment 22

16 years ago
Bug only exists in very specific environment which we can't replicate easily,
retargeting to future.
It's also possible that it's a necko bug.  Anybody from the necko team want to help?
-> future
-> p3 
Priority: -- → P3
Target Milestone: 2.0 → Future

Comment 23

16 years ago
My company just upgraded our firewall proxy and the problem has gone away (or
maybe 0.9.1 did something to fix it). It is still a bit worrying that IE, NN4,
and Lynx had no problem with the old firewall and I'm still attempting to
analyze the difference. However, the issue has lost its urgency. 

Comment 24

16 years ago
much changed for 0.9.1 ... i'd bet this was fixed on our end.

Comment 25

16 years ago
Marking worksforme. The download speed through a proxy now appears very quick.
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME

Comment 26

16 years ago
Verified worksforme. https://junruh/knox/color/color.html takes 3.5 seconds
through a proxy and 2.5 seconds without a proxy. Tha page has 100 small gif files.


13 years ago
Component: Security: UI → Security: UI
Product: PSM → Core


9 years ago
Version: psm2.0 → 1.0 Branch
VERIFIED WORKSFORME for almost 8 years.  Removing QAWANTED.
Keywords: qawanted
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.