When I try to access https://www.verisign.com 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.
sending to networking, CC'ing dougt
ssl proxy problem. Darin, you know anything about this?
I'll look into this.
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?
I downloaded build 2001022605 (via build bar at Mozillazine) and the problem still exists. One small difference, after trying to download https://www.verisign.com for a while, PSM crashes but the browser continues to work and I can browser non-secure pages.
I think the PSM folks should look into this. Regardless of what mozilla does, PSM shouldn't be crashing.
I agree. However, I am not the PSM folks. Reassigning.
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. Registers: 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.
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.
KenW do you have the Talkback ID from the crash?
Is anyone still seeing this in recent builds? Much has changed at the socket level.
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.
Thanks for the feedback! I'll be looking into this shortly.
I suspect there might be some problems (similar in nature to bug 31174) on the part of HTTP. Though I'm not really sure.
Setting to new and qawanted.
Is this still a problem with the most recent builds (using PSM2)?
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 www.verisign.com (http, not https). Get prompted for user id and pw, page loads fine. 2. Try https://www.versisign.com. 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 tunnel. 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
A bug in CONNECT was fixed over the weekend. Please try a 4/30 or later build.
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.
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.
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
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.
much changed for 0.9.1 ... i'd bet this was fixed on our end.
Marking worksforme. The download speed through a proxy now appears very quick.
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.
VERIFIED WORKSFORME for almost 8 years. Removing QAWANTED.