If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

RESOLVED FIXED in mozilla1.3final

Status

()

Core
Networking: HTTP
P1
critical
RESOLVED FIXED
15 years ago
15 years ago

People

(Reporter: Fredrik Aminoff, Assigned: Darin Fisher)

Tracking

({regression})

Trunk
mozilla1.3final
regression
Points:
---
Bug Flags:
blocking1.3 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fixed1.3, URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

15 years ago
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.
(Reporter)

Comment 1

15 years ago
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..
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: MacOS X → All
Hardware: Macintosh → All
(Reporter)

Comment 3

15 years ago
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 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??
(Reporter)

Comment 5

15 years ago
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

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

Comment 7

15 years ago
Confirming it with build 2003021008 under Windows XP SP1.
(Reporter)

Comment 8

15 years ago
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...
(Assignee)

Comment 9

15 years ago
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.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.3final
(Assignee)

Comment 10

15 years ago
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 :(
Flags: blocking1.3?
Keywords: regression
(Assignee)

Comment 11

15 years ago
Created attachment 115738 [details] [diff] [review]
v1 patch (minimal version)
(Assignee)

Comment 12

15 years ago
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).
(Assignee)

Comment 13

15 years ago
elevating severity to critical.  i can imagine much worse examples where this
same bug would cause trouble.
Severity: major → critical
Priority: -- → P1
(Assignee)

Comment 14

15 years ago
Created attachment 115780 [details] [diff] [review]
v1 patch (full version, not zipped)
Attachment #115739 - Attachment is obsolete: true

Updated

15 years ago
Flags: blocking1.3? → blocking1.3+
(Assignee)

Comment 15

15 years ago
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!
Attachment #115780 - Flags: superreview?(bzbarsky)
Attachment #115780 - Flags: review?(dougt)

Comment 16

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

r=dougt.  i would have picked a different function name. :-)
Attachment #115780 - Flags: review?(dougt) → review+
I'm not getting to this until best-case tomorrow (and more likely, Monday or later)

Updated

15 years ago
Summary: "Redirection limit exceeded" if https is left out, dosn't follow redirects → "Redirection limit exceeded" if https is left out, doesn't follow redirects
(Assignee)

Updated

15 years ago
Attachment #115780 - Flags: superreview?(bzbarsky) → superreview?(brendan)
Attachment #115780 - Flags: superreview?(brendan) → superreview+
(Assignee)

Comment 18

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

seeking drivers approval for 1.3 final.
Attachment #115780 - Flags: approval1.3?

Comment 19

15 years ago
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.
Attachment #115780 - Flags: approval1.3? → approval1.3+
(Assignee)

Comment 20

15 years ago
fixed1.3
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Updated

15 years ago
Whiteboard: fixed1.3
You need to log in before you can comment on or make changes to this bug.