4 ms·

Hey, I'm the creator of the blogging platform he's running on and am trying to replicate this. Do you have cookies or js off or any other notable change from st

by tynan 14y ago

Hey, I'm the creator of the blogging platform he's running on and am trying to replicate this. Do you have cookies or js off or any other notable change from stock?

mongol 14y ago
Third party cookies off in my case
eCa 14y ago
Cookies & js on. I do use a few addons (Flashblock, Adblock plus, Ghostery) that possibly could cause side effects, but since Chrome also causes problems for some I doubt that it's a Firefox specific bug.
wavesplash 14y ago
Same redirect loop problem in Chrome/Linux. Addons: Adblock, Disconnect, Ghostery. 3rd party cookies disabled.
tynan 14y ago
Thanks a lot for the info, everyone. I can't replicate this even with all the same addons installed, but I'm working on it...
- wiredfool 14y ago
  Did it for me with ghostery only, chrome Version 24.0.1312.57 on osx 10.7. Escape stopped the insanity.
- nikoftime 14y ago
  I got the same thing in Safari 6.0.2 (stock install) on latest Mac OS X
damoncali 14y ago
I got a weird and similar problem. The page looked like it was just continually reloading parts (most) of itself, 2 to 3 times per second. I stopped if I clicked the stop button and all was well. Chrome for mac, normal config except 3rd party cookies blocked. Google Page Insights and YSlow enabled.
tynan 14y ago
I believe this issue is fixed now... feel free to give it a try and let me know if you're still having issues. Thanks to everyone for the detailed info-- really helped me a lot. For those interested, here's what happened: When someone goes to a SETT blog, the first thing we do is fire off an ajax call to see if we can set a 3rd party cookie. If we can't, we bounce to a page on sett.com that sets a cookie and then redirects back. In some cases, like Safari with default settings, this allows us to use a 3rd party cookie. To prevent infinite looping in cases where 3rd party cookies can't be accessed, we add a query string to the URL, telling SETT to skip the cookie check. However, the old way we were doing it was just appending ?_ to the URL, rather than parsing it out and taking into consideration the query string of the URL. This URL was submitted with a trailing ?, which made the query string ??_, which didn't properly skip the cookie check. Thus... infinite refreshes.
- eCa 14y ago
  Yes, the redirect is gone now.

by tynan 14y ago

Hey, I'm the creator of the blogging platform he's running on and am trying to replicate this. Do you have cookies or js off or any other notable change from stock?

mongol 14y ago

Third party cookies off in my case

eCa 14y ago

Cookies & js on. I do use a few addons (Flashblock, Adblock plus, Ghostery) that possibly could cause side effects, but since Chrome also causes problems for some I doubt that it's a Firefox specific bug.

wavesplash 14y ago

Same redirect loop problem in Chrome/Linux. Addons: Adblock, Disconnect, Ghostery. 3rd party cookies disabled.

tynan 14y ago

Thanks a lot for the info, everyone. I can't replicate this even with all the same addons installed, but I'm working on it...

wiredfool 14y ago
Did it for me with ghostery only, chrome Version 24.0.1312.57 on osx 10.7. Escape stopped the insanity.
nikoftime 14y ago
I got the same thing in Safari 6.0.2 (stock install) on latest Mac OS X

damoncali 14y ago

I got a weird and similar problem. The page looked like it was just continually reloading parts (most) of itself, 2 to 3 times per second. I stopped if I clicked the stop button and all was well. Chrome for mac, normal config except 3rd party cookies blocked. Google Page Insights and YSlow enabled.

tynan 14y ago

I believe this issue is fixed now... feel free to give it a try and let me know if you're still having issues. Thanks to everyone for the detailed info-- really helped me a lot. For those interested, here's what happened: When someone goes to a SETT blog, the first thing we do is fire off an ajax call to see if we can set a 3rd party cookie. If we can't, we bounce to a page on sett.com that sets a cookie and then redirects back. In some cases, like Safari with default settings, this allows us to use a 3rd party cookie. To prevent infinite looping in cases where 3rd party cookies can't be accessed, we add a query string to the URL, telling SETT to skip the cookie check. However, the old way we were doing it was just appending ?_ to the URL, rather than parsing it out and taking into consideration the query string of the URL. This URL was submitted with a trailing ?, which made the query string ??_, which didn't properly skip the cookie check. Thus... infinite refreshes.

eCa 14y ago
Yes, the redirect is gone now.