194708 - "Redirection limit exceeded" if https is left out, doesn't follow redirects

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect, P1)

Description

[Fredrik Aminoff]

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.

Comment 1

[Fredrik Aminoff]

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 

Comment 2

[Matthias Versen [:Matti]]

confirming with win2k build 20030224..

Comment 3

[Fredrik Aminoff]

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

Comment 4

[Boris Zbarsky [:bzbarsky]]

~% telnet boka.island.liu.se 80
Trying 130.236.248.22...
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 130.236.248.32...
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??

Comment 5

[Fredrik Aminoff]

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)

Comment 6

[tenthumbs]

FWIW, s_client -bugs gets farther and I can get a HEAD response. There 
may be multiple problems here.

Comment 7

[joakim_46]

Confirming it with build 2003021008 under Windows XP SP1.

Comment 8

[Fredrik Aminoff]

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...

Comment 9

[Darin Fisher]

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.

Comment 10

[Darin Fisher]

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 :(

Comment 11

[Darin Fisher]

Attachment: v1 patch (minimal version)

Comment 12

[Darin Fisher]

Attachment: 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).

Comment 13

[Darin Fisher]

elevating severity to critical.  i can imagine much worse examples where this
same bug would cause trouble.

Comment 14

[Darin Fisher]

Attachment: v1 patch (full version, not zipped)

Comment 15

[Darin Fisher]

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 16

[Doug Turner (:dougt)]

Comment on attachment 115780 [details] [diff] [review]
v1 patch (full version, not zipped)

r=dougt.  i would have picked a different function name. :-)

Comment 17

[Boris Zbarsky [:bzbarsky]]

I'm not getting to this until best-case tomorrow (and more likely, Monday or later)

Comment 18

[Darin Fisher]

Comment on attachment 115780 [details] [diff] [review]
v1 patch (full version, not zipped)

seeking drivers approval for 1.3 final.

Comment 19

[Asa Dotzler [:asa]]

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.

Comment 20

[Darin Fisher]

fixed1.3
fixed-on-trunk