User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b) Gecko/20030223 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b) Gecko/20030223 When entering molly.island.liu.se into the location bar all I get is: "Redirection limit for this URL exceeded" And the page is not displayed. But if i enter https:// in front the page loads ok. The actual server has a redirect to the HTTPS-port but this doesn't work. It has worked in all earlier mozillabuilds and work in all other browsers but Mozilla doesn't seem to follow the redirect. Reproducible: Always Steps to Reproduce: 1. Enter molly.island.liu.se into the location bar 2. 3. Actual Results: Mozilla gets into a loop and then says: "Redirection limit for this URL exceeded." Expected Results: Follow the redirect and load the correct page.
This error also occurs in my win32-build (1.3b): Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210
confirming with win2k build 20030224..
It seems that if the page has been visited on the "correct" URL it works to just enter the hostname. But I'm not sure. Here is another adress that gives the same symptom: boka.island.liu.se
~% telnet boka.island.liu.se 80 Trying 18.104.22.168... Connected to boka.island.liu.se. Escape character is '^]'. GET / HTTP/1.0 Host: boka.island.liu.se HTTP/1.0 301 Redirect to secure server Location: https://boka.island.liu.se:80/ ~% telnet molly.island.liu.se 80 Trying 22.214.171.124... Connected to molly.island.liu.se. Escape character is '^]'. GET / HTTP/1.0 Host: molly.island.liu.se HTTP/1.0 301 Redirect to secure server Location: https://molly.island.liu.se:80/ So those are most certainly _not_ "redirect to the HTTPS-port". Quite the opposite, in fact.... That said, there _does_ seem to be a valid SSL-ish server running on port 80 (in addition to the normal server): ~% openssl s_client -connect molly.island.liu.se:443 CONNECTED(00000003) depth=1 /C=SE/ST=\xD6sterg\xF6tland/O=Link\xF6ping University/OU=UNIT/CN=UNIT Best-Effort CA 2nd SSL Signing Certificate verify error:num=20:unable to get local issuer certificate verify return:0 19577:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:216: (I don't have the cert it expects, looks like). Are we keying off port in preference to scheme here??
You are correct. It's not redirect to HTTPS-port it is redirect to the HTTPS-protocol. The webserver (Roxen in this case) senses that it is a HTTP-request on a HTTPS-port and sends a redirect to HTTPS. And yes, the webserver listens for SSL-requests on port 80. If you like the CA-certificate for some reason it can be downloaded here: http://www.unit.liu.se/services/ca/ Rotcertifikat i PEM-format (beca-root-pem.crt)
FWIW, s_client -bugs gets farther and I can get a HEAD response. There may be multiple problems here.
Confirming it with build 2003021008 under Windows XP SP1.
Will it be possible to get this bug fixed before the release of 1.3? I think it's kind of major that the browser ignores this kind of redirects...
i will investigate this for 1.3 final, but since it is almost out the door, there is not much chance that we'll have a chance to fix it for 1.3 final.
i think this should be blocking 1.3 final. it turns out to be a regression from bug 176919. the calls to SetCharAt in nsHttpConnectionInfo.cpp have their arguments reversed :(
Created attachment 115739 [details] [diff] [review] v1 patch (full version) this version of the patch includes some other fixes as well. for example, i noticed that the :80 was getting stripped from the URL bar. that happens to be a regression from a much older bug fix, probably during the late 1.2 or early 1.3 alpha cycle. this patch is zipped because the unzipped version was getting rejected by bugzilla (i have no idea why).
elevating severity to critical. i can imagine much worse examples where this same bug would cause trouble.
Created attachment 115780 [details] [diff] [review] v1 patch (full version, not zipped)
Comment on attachment 115780 [details] [diff] [review] v1 patch (full version, not zipped) dougt, bz: can you please review this 1.3 blocker fix. thx!
Comment on attachment 115780 [details] [diff] [review] v1 patch (full version, not zipped) r=dougt. i would have picked a different function name. :-)
I'm not getting to this until best-case tomorrow (and more likely, Monday or later)
Comment on attachment 115780 [details] [diff] [review] v1 patch (full version, not zipped) seeking drivers approval for 1.3 final.
Comment on attachment 115780 [details] [diff] [review] v1 patch (full version, not zipped) a=asa (on behalf of drivers) for checkin to the 1.3 branch.