668207 - 302 redirects without a domain, originating on an https site, are resulting in a fetch of the non-SSL URL

Status: RESOLVED INCOMPLETE

(Core :: Networking: HTTP, defect)

Description

[Mark Blackman]

Attachment: redirect_headers_ff5.txt

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0) Gecko/20100101 Firefox/4.0
Build ID: 20110318052756

Steps to reproduce:

I filled authentication credentials at  https://www.fairfx.com/login


Actual results:

After successful authentication, I was redirected to http://www.fairfx.com/your_account. Note the non-SSL URL.

Under *Firefox 4*, the expected interpretation of the 302 Location: header
took place and the browser was redirected to an *https* URL.

I've attached the relevant extract from a Live Headers add-on capture.


Expected results:

I should have been redirected to https://www.fairfx.com/your_account.

Comment 1

[Mark Blackman]

the "/your_account" references are mismrembered URL paths. It should have been "/youraccount"

Comment 2

[Benjamin Smedberg]

That is technically a malformed Location header: location headers MUST be an absolute path. However, I agree that if we did anything with relative paths, we should continue to redirect to the HTTPS site.

Comment 3

[Boris Zbarsky [:bzbarsky]]

That's... quite odd.  Location headers are resolved with the URI the request was made to as the base URI, so this should have Just Worked.

Mark, is this reliably reproducible?  If so, would you be willing to use http://harthur.github.com/mozregression/ to narrow down when this problem appeared?

Also, would you be willing to check whether it appears in Aurora builds?

Comment 4

[Bjarne (:bjarne)]

Fwiw, bug #618835 invalidates targets of cached Location/Content-Location headers using the literal value of the headers - relative uris are not resolved I believe. Other redirect-related bugs also use literal headers, afaik.

Marc, if you have the time and energy, could you follow https://developer.mozilla.org/en/HTTP_Logging, add ",cache:5" at the end of "set NSPR_LOG_MODULES" (enable cache-logging) and post the log here...?

Comment 5

[Boris Zbarsky [:bzbarsky]]

> relative uris are not resolved I believe

You believe incorrectly. ;)  The NewUri call there passes mURI as the base URI, so relative URIs are resolved relative to mURI.

Comment 6

[Bjarne (:bjarne)]

I stand corrected. :)

Comment 7

[Mark Blackman]

Ok, reviewing the RFC, I can see that indeed "Location: " is expected to start with a scheme and host before a path. However, I'd say it's pretty well established behaviour to redirect a path-only to the "origin" scheme+host across all mainstream browsers.

This is perfectly reproducible, but we will be closing this and a related bug on the server side ASAP, so I may knock up a test web server with the same behaviour. I'm prepared to spend a little bit of time isolating the revision(s) where this behaviour came in.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Mark, thanks!

If you can make a server showing the problem public, I could also do the narrowing down.  I just don't have credentials to log in to fairfx.com.  ;)

Comment 9

[Daniel Veditz [:dveditz]]

Mark: I think part of what comment 4 is saying is that our "Aurora" builds may have fixed this because we did fix another regression that was somewhat related. Could you please try Aurora? https://www.mozilla.com/firefox/channel/

Comment 10

[Boris Zbarsky [:bzbarsky]]

No, comment 4 is just confused.  ;)  The changes in that bug should not have affected behavior on the testcase as described in comment 0.

Comment 11

[Mark Blackman]

I've updated our live environment code to issue absolute URL redirects for the cases that concerned us most. I'm unlikely to be in a position to offer a testing server until next week though. Now that I've updated our server, I'm content for this report to be public, but not obvious to me how to make it publically viewable.

I will try Aurora on a test server at some point next week.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Let's keep this closed for the moment, until we figure out what's going on here...

Comment 13

[Bjarne (:bjarne)]

(In reply to comment #11)
> I'm unlikely to be in a position to offer
> a testing server until next week though. 

That would be very useful! I did a simple test trying to reproduce your issue, but it works fine afaics so I guess your site uses a more complex pattern of redirects than my test.

> I will try Aurora on a test server at some point next week.

...  and that would also be useful info, yes. :)

Comment 14

[Bjarne (:bjarne)]

Like stated in comment #11, their internal app has been updated to avoid this problem. Excerpt from private email:

----------
I finally came up with sample minimum web application to attempt to illustrate
the bug with FF5, but could not. 

So there's something very specific about our application which is triggering
the bug in FF5.

I might get a chance to run up an older version of our app to see if I can 
replicate and/or expose it to you.
----------

As this is proprietary code we will not receive a copy of the app in order to reproduce locally. Awaiting further action by reporter.

Comment 15

[Josh Aas]

I don't think we should depend on the reporter to come back to this bug. What is the next step assuming the reporter doesn't come back with more info? Open up the bug to get more info, maybe also mark it resolved incomplete until we get more info?

Comment 16

[Bjarne (:bjarne)]

Resolving as incomplete as discussed with team leader. Reassign to nobody, leaving to sec-team for how to proceed.

Comment 17

[Josh Aas]

We decided to resolve as incomplete because it appears that Bjarne has no way to move forward here.

Can we open up this bug to the public? Maybe having more eyes on it will help us get to the bottom of the issue, if there is one.

Comment 18

[Ian Melven :imelven]

reopening and assigning to me, with an aim to opening this up

Comment 19

[Ian Melven :imelven]

Discussed with bsterne and dveditz, we are opening this up in the hopes that other people experiencing this problem (if they are) can provide further details. From the above comments, it sounds like this is currently WORKSFORME...