HTTPSB on webpages with a redirect loop

[my-password-is-password]

1. Use "block-all/allow-exceptionally" approach
2. Go to http://na.alienwarearena.com/

The page doesn't load and HTTPSB's popup is blank. If you turn off HTTPSB and reload, the page loads fine. After that you can turn HTTPSB back on and when you try to visit http://na.alienwarearena.com/ again the popup is no longer blank.

HTTPSB 0.7.9.0 ( out-of-the-box settings )
Chromium 32 :)
Windows XP

[gorhill]

What an obnoxious web site (I am being polite, I had another expression in mind).

This web site absolutely wants to put cookies on your computer. So here is what is happening:

1. User makes first visit to the web site.
2. Web site sees no cookie in the header of first request.
3. Web site interprets this as a first visit.
4. In order to force cookies on the user's web site, server sends a redirect header along with a cookie header.
5. User's browser receives the cookie and redirect headers.
6. If user's browser blocks cookie, go to step 1., otherwise web site will display fine second time around.

HTTPSB blocks cookies as per user's choice, which means the web site always interprets the lack of cookie header as a sign of first time visit, and keep repeating the steps 1. to 5. above.

The web site doesn't accept users may want to opt out of sending cookies. This web site could at least allow the first request to go all fine, and gently warn user that cookies are required for the web site to work properly. But they chose the obnoxious approach.

So, there is no fix.

Mitigation for a HTTPSB user in BA/AX mode, is to import the following rule:

*%0A%09whitelist%0A%09%09cookie%20na.ali
enwarearena.com%0A

Of course, any other web sites behaving similarly would require his own special rule.

I don't think hacking HTTPSB to accommodate such sites to be a proper solution. The web site needs to be fixed.

[my-password-is-password]

Sounds good to me. Thank you

[my-password-is-password]

I installed an older version of HTTPSB and in HTTP Switchboard 0.7.6.1 it worked. The popup isn't blank when you visit the site for the 1st time. Starting from 0.7.7.0 on, the popup is blank. How did it work back then?

[gorhill]

Let me try this, I will report back.

I just tried with v0.7.6.1 and got the same result, infinite redirection by the site. The only way for the site to not fall into an infinite redirection is to give it his cookies. So somehow in your test it got its cookies.

[my-password-is-password]

I get the infinite redirect too but does your popup have the matrix? Mine did and I didn't have to turn off HTTTPSB.

Here were the rules that were used for v0.7.6.1. I think its the default.

http%3A%2F%2Fchromium-behind-the-scene%0
A%09whitelist%0A%09%09_%20_%0A_%0A%09whi
telist%0A%09%09image%20_%0A%09%09stylesh
eet%20_%0A%09blacklist%0A%09%09sub_frame
%20_%0A%09%09_%20_%0A

v0.7.6.1

v0.7.9.0

[gorhill]

I get the infinite redirect too but does your popup have the matrix? Mine did and I didn't have to turn off HTTTPSB

You're right, I see the matrix with v0.7.6.1. With the matrix at least the user has a way out (allow cookies).

Thinking about it, it probably has to do with my code to handle and report redirects. Now the reporting is delayed until the final landing page has finally been fetched, so that I can report in the matrix all intermediary requests. Before these were not visible in the matrix of the landing page. Problem now with sites like alienwarearena.com is that there is no final landing page.

So I need to find a way to report all the redirects even when we never arrive at destination.

Thanks for your persistence to investigate, I had assumed the matrix was never shown before. I can think of a quick fix, but this would cause properly working redirects to be shown chronologically after the landing page in the log in the Statistics page, something I wanted to avoid when I landed the report of redirects.

[gorhill]

chrome.webRequest.onErrorOccurred.addListener returns ERR_TOO_MANY_REDIRECTS:

error: "net::ERR_TOO_MANY_REDIRECTS"
frameId: 0
fromCache: false
ip: "54.243.40.56"
method: "GET"
parentFrameId: -1
requestId: "190408"
tabId: 441
timeStamp: 1390888622577.967
type: "main_frame"
url: "http://na.alienwarearena.com/"

So this appears to be the solution of choice so far.