New issue
Advanced search Search tips
Starred by 23 users
Status: WontFix
Owner:
Closed: Mar 2015
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

Blocking:
issue 390162



Sign in to add a comment
twitter not working
Reported by ghost...@gmail.com, Oct 3 2014 Back to list
UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.7 Safari/537.36

Example URL:
https://twitter.com/

Steps to reproduce the problem:
1. Go to https://twitter.com/

What is the expected behavior?
Twitter loads

What went wrong?
This webpage is not available

The webpage at https://twitter.com/ might be temporarily down or it may have moved permanently to a new web address.

Error code: ERR_CONNECTION_CLOSED

Did this work before? Yes Yesterday

Chrome version: 39.0.2171.7  Channel: dev
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 15.0 r0
 
Comment 1 by ghost...@gmail.com, Oct 4 2014
It works in other browsers and in incognito.

The same thing happened a few weeks ago -  issue 408944 
Having the same issues. It was doing it prior to this day as well.

Regards
Looks like the old SPDY bug is back. Twitter seems to load on initial loading. But then it doesn't allow you to scroll down. And once you refresh after the initial load you either get the error:

Error code: ERR_CONNECTION_CLOSED

or it displays a blank page with the words: Not Found

And if you relaunch twitter.com in an incognito session, you then end up with the SPDY error:

Error code: ERR_SPDY_COMPRESSION_ERROR

Can you create an option/switch in Chrome to bypass the SPDY protocol? This is becoming annoying..


tested with the following version, and settings:

Google Chrome	39.0.2171.7 (Official Build) dev-m
Revision	fde783d0141b3de9ba58bca74ad3eb98d9b3c184-refs/branch-heads/2171@{#19}
OS	Windows 
Blink	537.36 (@182806)
JavaScript	V8 3.29.88.1
Flash	15.0.0.189
User Agent	Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.7 Safari/537.36
Command Line	
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --flag-switches-begin --enable-experimental-app-list --enable-experimental-hotwording --enable-experimental-web-platform-features --enable-extension-action-redesign --google-profile-info --enable-material-design-ntp --enable-nacl --enable-sync-app-list --enable-sync-synced-notifications --ignore-gpu-blacklist --enable-lcd-text --flag-switches-end
Executable Path	C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
Profile Path	C:\Users\rgo20641\AppData\Local\Google\Chrome\User Data\Default

Variations	
d0bd833b-3f4a17df
f2d919bf-3f4a17df
74785582-3f4a17df
e950616e-71831d5d
e9f4800b-39c30599
8afebf76-3d26599e
f1eb96ab-3d47f4f4
19f73432-ca7d8d80
76b48ab8-a2567007
c70841c8-4866ef6e
15e1b27b-3d47f4f4
195ce1b5-d93a0620
4b406b23-ec775de4
1d3ad72e-c6a65085
9e5c75f1-211587a8
f79cb77b-3d47f4f4
89ddaf11-13b263c7
24dca50e-c4e4c5f
ca65a9fe-91ac3782
8d790604-ccebe2f3
4ea303a6-3f4a17df
d8f57532-3f4a17df
61544484-ca7d8d80
b310ecc7-fcf6c09
313d831b-e7104fc
9736de91-ca7d8d80
ea1014b7-dd21eb5a
5a3c10b5-e1cc0f14
244ca1ac-4ad60575
5e29d81-f23d1dea
3ac60855-486e2a9c
246fb659-4ad60575
f296190c-e7e0c21f
4442aae2-75cb33fc
ed1d377-e1cc0f14
75f0f0a0-4ad60575
e2b18481-a5822863
e7e71889-e1cc0f14
aff9bdb8-ca7d8d80
cbf0c14e-bf3e6cfd
Labels: Cr-Internals-Network-SPDY
Could one of you guys upload a net-internals dump?  Instructions here:  https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details
Net internals file attached.

Version 39.0.2171.7 dev (64-bit) on Mac
net-internals-log.json
286 KB Download
Both https://code.google.com/p/chromium/issues/detail?id=373811 and https://code.google.com/p/chromium/issues/detail?id=408944 suggest this is a Twitter server-side issue. However, it's only happening in dev builds of chrome? I've asked my friends, who all run not-dev builds...they aren't experiencing this. 

Version 39.0.2171.7 dev-m (64-bit)
Labels: -Pri-2 Pri-1 M-39
Owner: b...@chromium.org
Status: Assigned
If only in dev then this may be an http/2 issue (rather than spdy). 

bnc: Can you look into this?
Seems to be happening in Mac OSX version of Chrome too!
similar bug filed with h2-14 versions of firefox, twitter dev comments over there that its likely a server side update. https://bugzilla.mozilla.org/show_bug.cgi?id=1077806
39.0.2171.7 on Linux, too. Definitely a protocol thing.

(Similar thing happened a month or so ago, fiddling with disabling SPDY kind of helped.)

Comment 12 by amin...@google.com, Oct 10 2014
Labels: -M-39 MovedFrom-39 M-40
Moving all non essential bugs to the next Milestone.
Comment 13 by b...@chromium.org, Oct 21 2014
Status: Fixed
Issue presumably fixed on Twitter's side, see https://bugzilla.mozilla.org/show_bug.cgi?id=1077806#c26.
Not fixed, this has been a problem for me for over a week now, including the latest Chrome update.  Currently running 40.0.2209.0 dev-m.
+1 not fixed 40.0.2209.0 dev-m (64-bit)

It's probably on Twitter side, though. Reported to Bill Gallagher at https://bugzilla.mozilla.org/show_bug.cgi?id=1077806#c26
Thanks for reporting.
I just started having this issue with Twitter a few moments ago. I'm running Version 39.0.2171.62 beta (64-bit) incognito.
Screen Shot 2014-11-14 at 9.43.55 AM.png
61.3 KB View Download
Comment 18 by b...@chromium.org, Nov 17 2014
Status: Started
Labels: -Pri-1 -M-40 M-41 MovedFrom-40 Pri-2
This issue is Pri-1 but has already been moved once, therefore lowering to Pri-2 and moving to next milesone.
This is still happening, quite often. 

Version 41.0.2224.3 dev-m (64-bit)
Comment 21 by b...@chromium.org, Nov 24 2014
kidyelman:  Thank you for reporting.  While we are working on the problem, you can start Chrome with the --enable-npn-http command line flag, or disable SPDY4 in chrome://flags to work around this issue.
SPDY4 is disabled already in flags. 
Using the command line flag "--use-spdy=off" works for me.
Comment 24 by b...@chromium.org, Dec 1 2014
Blocking: chromium:390162
Comment 25 by Deleted ...@, Dec 4 2014
Been having this a few times this week on 2 different PCs in 2 different locations - both using Chrome dev (right now at v41.0.2236.0 dev-m) :( 

SPDY4 flag is already disabled.

Have seen this happening a lot with Twitter in the last few months - I thought it was possibly fixed until it returned this week. 

Twitter will load as normal, then when I either:
- Try to post a new tweet (Gives a 500)
- Scroll and reach the end of the page - the 'load more' functionality will die
- Trying to visit someone's profile or navigating away from the homepage will return 'This webpage is not available' and 'The webpage at https://twitter.com/.... might be temporarily down or it may have moved permanently to a new web address.' with the Error code: ERR_CONNECTION_CLOSED

Incognito and other browsers (IE11 + Firefox) work with no problems.
Comment 26 by Deleted ...@, Dec 9 2014
net-internals-log.json
512 KB Download
Sometimes I get 404 OK when requesting twitter.com (and sometimes I get ERR_CONNECTION_CLOSED like everyone else). Is this related to this issue, or something else?
404 OK.png
17.4 KB View Download
The issue went away for a bit, but this has started happening again, I have SPDY disabled in flags; and the previously mentioned npn-http flag in my Chrome target path. running: Version 41.0.2243.0 dev-m (64-bit)
Labels: -M-41 MovedFrom-41
This issue has already been moved once and is lower than Priority 1,therefore removing mstone.
Labels: -Cr-Internals-Network-SPDY Cr-Internals-Network-HTTP2
Migrate from Cr-Internals-Network-SPDY to Cr-Internals-Network-HTTP2
We had two people with a very similar issue here, this morning: it worked yesterday, but today we were getting "net::ERR_CONNECTION_CLOSED".

Chrome 41.0.2272.89 (32-bit), Windows 7, reaching a HTTPS server on `localhost` with a self-signed certificate.

Connection to the same application on its staging and prod environments were successful; we just couldn't connect to our local development machines.

Our server logs didn't show any activity, as if chrome never reached the server.  We suspected a SSL issue.

We found this other page: http://googleonlinesecurity.blogspot.co.uk/2014/09/gradually-sunsetting-sha-1.html

Our staging and prod environment used SHA256 certs, but our local dev machines still used SHA1.

We were eventually able to fix our issue by regenerating a self-signed certificate, using SHA256.

If the site certificate is really the issue - which it appears to be - it might be worth fixing this bug, to give users better feedback...  "net::ERR_CONNECTION_CLOSED" wasn't very helpful.

gilbert.dave71:  This issue is for a problem apparently related to talking to Twitter over HTTP/2, which sounds nothing like your issue.  ERR_CONNECTION_CLOSED just means a socket was unexpectedly closed on us (Like if Twitter doesn't like our HTTP/2 frames).

Please file a new bug for the issue you're running into.
Comment 33 by b...@chromium.org, Mar 31 2015
Status: WontFix
Closing ticket for lack of activity.  If problem persist, feel free to reopen, and please provide net-logs.
Comment 34 by bdrew...@gmail.com, May 26 2015
Not directly related to twitter but I had pretty much the same issue with my own site while using nginx. The issue is described and fixed at http://trac.nginx.org/nginx/ticket/428
Comment 35 by b...@chromium.org, Jun 1 2015
Re: #34.  Thanks for the heads up.  It's always comforting to see a mystery being solved.
Sign in to add a comment