when I try to login to https://mbed.org/account/login/ my browser shows a "redirection error"!

I allow all cookies from *.mbed.org until the end of the firefox session!

The direct link from mbed.ord to the longin page never works for me, the only way I can login is to allow all cookies until they expire and do a direct call to https://mbed.org/account/login/ .

Even then I must close firefox several times until I don't see the redirection errror!

I use Win 7 and Firefox  3.6.3

regards

Thomas

In address window, type: about:config

Search for redirection, and set the ratio for about 50. That should do it.

No, that don't work for me!

I fond only one redirection on config:  network.http.redirection-limit it was on 20. I changed it to 50.

Same as before!

Hi Dan

I just test it on a XP maschine. Everything work fine. Is this error only on Win 7 and Firefox ?

Thanks

Thomas

Hi Thomas,

I dont think it's only limited to win7 machines, as I've had reports of similar issues on XP machines, but the issues could never be reliably reproduced.

I've just made a small change now which may fix the problem - can you let me know if you are now able to login (by clicking the login link) ok? (on your win7 machine).

Thanks,

Dan

Hi Dan

yes on my Win 7 machine, I do the  ( login , logout , close Firefox , open Firefox ) sequence 15 times, I only once get a redirection error.

I can work with this!

Thanks for the quick fix!

Thomas

Hi Thomas,

After some pretty extensive troubleshooting, we think we have identified and fixed the root cause of this problem. It should hopefully not happen again. This is really satisfying as it's something that has been lingering for quite a while.

If it does somehow happen again, please let me know.

Thanks for the bug report!

Dan

Hi Dan

thank's for fixing this problem. I sometimes do also some web programming, mostly PHP. So I am very interested to hear where the problems was.

Maybe you can tell a little more? Was it a timeout problem?

Thomas

Hi Thomas,

Sure, here goes...

A little bit about our setup -

In addition to having separate groups of servers for the different tasks (general website and compiler), we have a three layer route in for inbound requests. There's a SSL endpoint layer, then a caching and load balancer layer, and then finally it reaches the application server, which in the case of the web site, has it's own caching system. So that's two caches in play.

Getting to the problem -

Now a rule of the middle caching layer is that it only caches requests not associated with a cookie, and media (images, etc). The application server caches responses to non-authenticated clients.

Finally, we have a mechanism which redirects you to the SSL version of the site if you are at a location that should be SSL (ie the login page) and back to the normal site if your location shouldn't be SSL. The SSL endpoint converts the SSL traffic to normal http, and adds a request header to let our application server know that the request was originally secure. So far so good.

All responses to a client with no mbed.org cookies present at all were being cached by the middle caching layer, as it happens. However  - 3xx redirects were being cached too. To put the final boot in, the middle caching layer is unaware of which requests were secure or not, so it sent the same cached response back for http://mbed.org/foo as it would for https://mbed.org/foo. So all that means that if you visited http://mbed.org/account/login and got a response redirecting you to the https version of that page, the cached response (which is a redirect) would be returned to you every time, hence a redirect loop!

The problem was not visible to the vast majority of people since they either kept around the cookies from last time or browsed the site enough before trying to log in that they picked up some mbed.org cookies from either trac or google analytics - it didn't matter what cookie so long as they had at least one.

The solution then was easy - don't cache non-media requests at the middle layer even if there are no cookies present!

Thanks Dan!

That makes us appreciate the work and thought put in the infrastructure behind what seems to be relatively simple website.