Closed Bug 491558 Opened 16 years ago Closed 16 years ago

HTTP STATUS 302 returned from buglist.cgi

Categories

(Bugzilla :: Query/Bug List, defect)

Product:
Bugzilla
Component:
Query/Bug List
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: Frank, Unassigned)

Details

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; de-de) AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1 Build Identifier: 3.3.4 When an client execute buglist.cgi for an version 3.3.4 Bugzilaa installation HTTP Status 302 is returned. Bugzilla Version 3.2.3 return the expected 200 as the status. Reproducible: Always Steps to Reproduce: 1. From an client execute http://.../buglist.cgi?short_desc_type=allwordssubstr&short_desc=&order=Importance&ctype=rdf Actual Results: HTTP Status 302 Expected Results: HTTP Status 200 Bugzilla 3.2.3 works like expected.
This happens if you access Bugzilla using http:// and Bugzilla forces to use https://.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → INVALID
(In reply to comment #1) > This happens if you access Bugzilla using http:// and Bugzilla forces to use > https://. OK, what forces Bugzilla to use https:// In my test enviroment I only use http should I change this to generely use https instead?
Bugzilla forces to use https:// when the 'ssl' parameter is set to 'always' (or 'authenticated sessions' and you are logged in).
(In reply to comment #3) > Bugzilla forces to use https:// when the 'ssl' parameter is set to 'always' (or > 'authenticated sessions' and you are logged in). I looked in my settings and found that the 'ssl' parameter is set to 'never' so is there an other reason for switching to ssl. For me it looks like som new code between Bugzilla 3.2.3 and 3.3.4 force this.
I'm seeing the same behavior as well on another 3.3.4 install with no ssl support. Is this an intended change?
(In reply to comment #5) > I'm seeing the same behavior as well on another 3.3.4 install with no ssl > support. Is this an intended change? Please can someone verify that this in not an unintended side effect!
Turns out this behavior was introduced on bug#15809. Leaving resolved invalid.
You need to log in before you can comment on or make changes to this bug.