Did you try clearing your cookies?

On ubuntu with chrome stable (58.0.3029.96), edition.pagesuite.com worked fine for me.

Deleted all cookies with pagesuite. No change in visible login attempt, 
did not look at log. Reluctant to remove all boston globe cookies - I'm 
sure it'd be easier for me just to use Firefox. Certainly no problem 
just going to edition.pagesuite.com, but that does not get the newspaper 
- I have no idea as to the meaning of appended info when the Boston 
Globe tries the access.

Please note this is a regression. Ver. 57 worked imperfectly and earlier 
versions worked well.


On 05/04/2017 05:31 PM, ckra… via monorail wrote:

Thank you for providing more feedback. Adding requester "ckrasic@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

How about from an incognito tab/window?

Incognito window get "different" results - The Globe's opening display 
indicating further loading appears, and moving parts move. When the 
progress display gets to loaded the operation either repeats or reloads 
(I don't know which) every few seconds with the progress indicator 
restarting from zero.

I tried to get a Network Log of the above and found access worked to the 
point of subscriber login. (I did not go on as LastPass is not available 
in incognito, but the point is things worked.) Both situations are 
repeatable.


On 05/04/2017 07:05 PM, ckra… via monorail wrote:

Thank you for providing more feedback. Adding requester "ckrasic@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Hi peter.brewster.7@, it looks like http://epaper.bostonglobe.com/ is being handled by "extension AdBlock."

Could you disable that extension and try again?

In ordinary Chromium page, pausing Adblock before requesting the page 
makes no observable difference. I still get the ERR_TOO... . Pausing 
Adblock and using an Incognito window works correctly - pages load 
quickly, subscriber login is good, and epaper is good. (And the 
crossword works.)

Oops! The incognito window now seems to working correctly, with or 
without Adblock paused. My guess is that this is related to less traffic 
at 11:30 vs. 8:00. See my reply to Comment #4.

Incidentally, on an ordinary failing attempt, Adblock reports zero ads 
blocked. Of course Adblock report is not available in Incognito window - 
I have no idea if target site can even sense or if Adblock has any effect.


On 05/05/2017 09:28 AM, xunji… via monorail wrote:

Thank you for providing more feedback. Adding requester "xunjieli@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I suspect the AdBlock extension is at fault here. Can you completely disable AdBlock rather than pausing it? You can see the list of extensions installed at chrome://extensions/, uncheck "Enable" button and try again.

I disabled AdBlock and there was no change from previous observations - 
the ePaper does not show up  and the ERR_TOO_ ... does. I reenabled and 
also checked to enable AdBlock in Incognito mode - likewise there was no 
change from previous observations. The ePaper loaded, albeit after an 
apparent delay.

AbBlock is Ver 3.10.0 (auto update) and I do not know when the most 
recent updates took place. Options are "as loaded" and I did not see 
anything that I thought might have an effect here.

On 05/08/2017 12:57 PM, xunji… via monorail wrote:

Thank you for providing more feedback. Adding requester "xunjieli@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Tested this issue on Ubuntu 14.04,checked with version #58.0.3029.81 by enabling and disabling the AdBlock extension,there are no changes from previous observations and no ERR_TOO_ ... 

First, google "err_too_many_redirects chrome" and notice that this 
problem is both not new and is sporadic. Also there are a lot of similar 
reports.

Second, in my case ERR_TOO became solid with Ver. 58., and was 
occasional (but seemingly unpredictable) with Ver. 57. Perhaps half the 
days when I went to get the ePaper. I have no recollection of when the 
problem first showed up for me.


On 05/09/2017 05:15 AM, rkalavak… via monorail wrote:

Thanks for your feedback! Looking at net log in original bug report I see multiple extensions affecting the response:

t=13271 [st=12212]   +URL_REQUEST_DELEGATE  [dt=3]
t=13271 [st=12212]      DELEGATE_INFO  [dt=1]
                        --> delegate_blocked_by = "extension AdBlock"
t=13272 [st=12213]      DELEGATE_INFO  [dt=1]
                        --> delegate_blocked_by = "extension Disconnect"
t=13273 [st=12214]      DELEGATE_INFO  [dt=1]
                        --> delegate_blocked_by = "extension HTTPS Everywhere"

I also do see that request being redirected 20 times forming a loop:

...

t=11158 [st=10099]      URL_REQUEST_REDIRECTED
                        --> location = "http://epaper.bostonglobe.com/html5/reader/production/default.aspx?pubname=&pubid=2c60291d-c20c-4780-9829-b3d9a12687cf&edid=65052af4-c7f3-4fc1-9ba5-eda456643640"

t=11371 [st=10312]      URL_REQUEST_REDIRECTED
                        --> location = "http://edition.pagesuite.com/launch.aspx?eid=65052af4-c7f3-4fc1-9ba5-eda456643640&error=1&debug=2c60291d-c20c-4780-9829-b3d9a12687cf"

t=12056 [st=10997]      URL_REQUEST_REDIRECTED
                        --> location = "http://epaper.bostonglobe.com/launch.aspx?eid=65052af4-c7f3-4fc1-9ba5-eda456643640"

t=13271 [st=12212]      URL_REQUEST_REDIRECTED
                        --> location = "http://epaper.bostonglobe.com/html5/reader/production/default.aspx?pubname=&pubid=2c60291d-c20c-4780-9829-b3d9a12687cf&edid=65052af4-c7f3-4fc1-9ba5-eda456643640"

t=13469 [st=12410]      URL_REQUEST_REDIRECTED
                        --> location = "http://edition.pagesuite.com/launch.aspx?eid=65052af4-c7f3-4fc1-9ba5-eda456643640&error=1&debug=2c60291d-c20c-4780-9829-b3d9a12687cf"

It appears to be functioning as expected. 

Could you get a net log while reproducing this WITH ALL EXTENSIONS DISABLED to confirm whether this is caused by the server or one of the extensions.

   

I disabled AdBlock, Disconnect and HTTPS Everywhere. Netlog attached. No 
observable effect and ERR_TOO_ still is result. Also no change in 
Incognito window.

However - Enable all three extensions causes Incognito window to fail 
with ERR_TOO_. Disable HTTPS Everywhere returns to correct operation 
regardless of AdBlock and Disconnect. Having only HTTPS Everywhere 
enabled fails and I have attached a second netlog showing ERR_TOO_.


On 05/09/2017 12:34 PM, m… via monorail wrote:

Thank you for providing more feedback. Adding requester "mef@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Thanks for confirmation! I've installed the HTTPS Everywhere extension, and it is indeed causing http://epaper.bostonglobe.com/ fail with ERR_TOO_MANY_REDIRECTS pointing to http://edition.pagesuite.com/launch.aspx?eid=2914303f-2725-4ea7-8992-17f4c9307a1b&error=1&debug=2c60291d-c20c-4780-9829-b3d9a12687cf

This is problem with the extension and should be reported to developers of Https Everywhere at https://github.com/EFForg/https-everywhere/issues/

I believe that Chrome is working as intended and there is nothing to fix.

Quick followup - uninstall of HTTPS Everywhere extension does NOT resolve the issue unless you clear cookies and local storage for epaper.bostonglobe.com and edition.pagesuite.com.