From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14-15mdk i686; en-US; m18) Gecko/20001010 BuildID: 2000101015 When a Web server send this header: Cache-Control: no-store Pragma: no-cache URI: http://www.mail.freesurf.fr/cgi-bin/sqwebmail?index=1 This is displayed as text file and I must copy/paste the URL to view the next page. Reproducible: Always Steps to Reproduce: Go to www.freesurf.fr and log in as "bugzilla", password "bugzilla" (I've created this account for this purpose). Then click on WebMail... Sorry the site is in french, but that shouldn't be a real problem Actual Results: Cache-Control: no-store Pragma: no-cache URI: http://www.mail.freesurf.fr/cgi-bin/sqwebmail?index=1 Expected Results: URL redirection to http://www.mail.freesurf.fr/cgi-bin/sqwebmail?index=1

I'm not quite sure what is going on here. Tom-cache issue? Any thoughts? -d

Looks like nsHTTPChannel is ignoring the 303 HTTP response. The SPEC (rfc2616) says we can for the most part treat a 303 like a 302. Attaching a patch that makes it so...

Adding keyword RTM

r=gagan

I'm happy with this change. I'm not sure about the 307 case which you mentioned in email though. I could be convinced to treat a 307 the same way but I'm not really sure. I'd yield to gagan's knowledge on that one. sr=mscott for this 303 case.

This bug is in candidate limbo. We will reconsider this fix once we have a candidate in hand, but we can't take this fix before then.

Moving to rtm+

The fix is now on the trunk.

We are moving toward the candidate. Please check this fix into the trunk so we can get get some cook time.

The fix is on the trunk.

PDT marking [rtm++]. This bug is now out of limbo and approved for checkin to the branch. Please check in ASAP.

Ok, this fix is now on the branch as well.

marking fixed

I am trying to reproduce/verify this bug, but www.freesurf.fr doesn't exist. I get an error back about this. Can you clarify?

The web site may have just been down... it is working now, and it appears that they have changed the main page considerably. You can repro/test this bug by entering bugzilla for the username and password in the login box on the upper right hand side of the page. Before the fix, all you would see is a bunch of HTTP headers displayed on the screen. Now, with the fix, you get the intended page.

Verified fixed on WinNT with 110109 build.

I've verified this on Linux and Mac builds 20001101. The page looks fine after I log in.

*** Bug 56496 has been marked as a duplicate of this bug. ***

*** Bug 55870 has been marked as a duplicate of this bug. ***