9096 - failure to load anything when behind a proxy (with tcp/80 blocked)

Status: VERIFIED DUPLICATE of bug 8559

(Core :: Networking, defect, P3)

Description

[Cyrille Chepelov]

Steps to Reproduce:
                  1) put a machine on a subnet
                  2) block access through port 80 on that subnet
                  3) mandate access through a proxy server (squid)
                  4) ask for a proxy server in prefs50.js (manually, the
                        UI is lagging behind)
                  5) try to load an object outside the subnet, through http
Actual Results:
                  6) bang, assertion failed in mkgeturl.c:3326, bing, core dump.

Expected Results:
        either :
                  6a) the page is loaded (correct behaviour)
         or :     6b) a page "no route to host" or "can't connect server"
                      is displayed (gracefully degraded mode).

Build Date & Platform Bug Found:
  Build ID# 1999062312
(however, this has been on for ages, with various compilers
(egcs-1.1.2, gcc-2.7.2.3))


Additional Information:

The machine which runs mozilla is behind two routers which will both
forbide direct access through port tcp/80 ; I have control on only one of
them --> using a proxy is mandatory.
   - *.crans.ens-cachan.fr is our domain ; I can successfully view (almost
?) any page within that domain.
   - proxy.crans.ens-cachan.fr:3128 is, well, our proxy server ; the only
machine allowed to speak http to the outside.
   - 194.80.29.2 is outside our domain (it's a part of
www.technosphere.co.uk)
   - so is www.mozilla.org (I bet you know better than me).

  compiler is egcs/gcc-2.95 snapshot 19990615, running on an autorpm'd
RH6.0 system. Processor is an AMD K6-200, older stepping B.

First trace (loading
http://www.crans.ens-cachan.fr/~chepelov/ts-priv-c.html, which makes use
of IMGs *outside* our domain)

\begin{trace}
Document http://www.crans.ens-cachan.fr/ loaded successfully
Document: Done (8.663 secs)
Document http://www.crans.ens-cachan.fr/pages-index.html loaded successfully
Document: Done (12.683 secs)
Document http://www.crans.ens-cachan.fr/~chepelov/index.html loaded successfully
Document: Done (2.351 secs)
nsDocumentBindInfo::OnStopBinding: Load of URL
'http://194.80.29.2//technosphere/ts_arch/ts000675.jpg' failed.  Error code: 1
nsDocumentBindInfo::OnStopBinding: Load of URL
'http://194.80.29.2//technosphere/ts_arch/ts000645.jpg' failed.  Error code: 1
nsDocumentBindInfo::OnStopBinding: Load of URL
'http://194.80.29.2//technosphere/ts_arch/ts001153.jpg' failed.  Error code: 1
nsDocumentBindInfo::OnStopBinding: Load of URL
'http://194.80.29.2//technosphere/ts_arch/ts000700.jpg' failed.  Error code: 1
Assertion failure: 0, at mkgeturl.c:3326
zsh: abort (core dumped)  ./runmozilla
\end{trace}

Second trace : attempting to load http://www.mozilla.org
FindShortcut: in='http://www.mozilla.org'  out='null'
Assertion failure: 0, at mkgeturl.c:3326
zsh: abort (core dumped)  ./runmozilla

After digging a little into the code it looks like :
        1) mkgeturl.c/3326 is an assert statement, whose previous line
reads : /* couldn't find the active socket.  Shouldn't ever happen */
Well, this does... ; NET_ProcessNet() really shouldn't bang when there's
no route to the target host, should it ?

        2) mozilla should never have tried to directly talk to the outside
hosts ; it seems that the lower network layer is aware of proxies
(mkhttp.c in particular), the upper layers (prefs engine) looks to be
aware of them too, but the information seems to never be passed on.

I had added this to my prefs50.js :
user_pref("network.proxy.http", "proxy.crans.ens-cachan.fr");
user_pref("network.proxy.http_port", 3128);
user_pref("network.proxy.no_proxies_on", "crans.ens-cachan.fr;127.0.0.1");
user_pref("network.proxy.ssl", "proxy.crans.ens-cachan.fr");
user_pref("network.proxy.ssl_port", 3128);
user_pref("network.proxy.types", 1);
(after a first dig in the source). The reported behaviour is with these
lines on ; I tried again without these lines afterwards, same behaviour).


core dumps are incomplete and unreadable to my gdb, sorry.

Well, maybe this bug report is already obsolete ; I don't know exactly
what Necko is supposed to replace (is that mozilla/network/* ?)

Good luck.

Comment 1

[Cyrille Chepelov]

I had never (for cause) noticed that by default, mozilla is supposed to open
http://www.mozillazine.org ; for some strange reason, this bug doesn't show in
that case, I just have a "nsDocumentBindInfo::OnStopBinding: Load of URL
'http://www.mozillazine.org/' failed.  Error code: 1". No core dump. However (I
retried), if I load http://www.crans.ens-cachan.fr/~chepelov/technosphere.html,
I still get the core dump (oh, I just noticed that it happens at the third or
fourth simultaneous connection attempt ; an off-by-one error ?)

Comment 2

[Paul MacQuiddy]

*** This bug has been marked as a duplicate of 8559 ***

Comment 3

[leger]

Changing all Networking Library/Browser bugs to Networking-Core component for
Browser.

Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do
this in a bulk change.  If this happens, I will fix. ;-)

Comment 4

[leger]

Bulk move of all Networking-Core (to be deleted component) bugs to new
Networking component.