Forum Discussion
SPDY not working with Chrome browser on Android
Hi,
we're experimenting with SPDY profiles on LTM 11.4
SPDY seems to be working fine with spdy-enabled desktop browsers (Chrome, Firefox) and also with non-spdy browsers (IE, iPhone?)
The only browser, which can't get a connection to an spdy-enabled virtual server is Google Chrome on Android. There we get "ERR_CONNECTION_CLOSED" on the client.
On a tcpdump, the SSL-handshake seems ok, but then the loadbalancer ends the connection (FIN).
Might be a browser bug (though since Google invented SPDY, one would think SPDY on Google Chrome should be flawless).
Has anybody experienced the same, has any hints or can at least confirm this?
LTM: 11.4.1 Browser: Android Chrome 35.0.1916.138
Thank you in advance,
Markus
- wfaulk_98141Altostratus
I have opened an F5 support case about this. We'll see what happens.
- aheinz_2272NimbostratusHi, did you receive a solution from F5 support??
- wfaulk_98141Altostratus
I'm seeing the same problem, but my Wireshark does support SPDY. The transaction looks like this:
- Client opens TCP connection
- SSL handshaking
- Server sends SPDY: SETTINGS, MAX_CONCURRENT_STREAMS: 10, INITIAL_WINDOW_SIZE: 32768
- Client closes TCP connection
- Client opens TCP connection
- SSL handshaking
- Server sends SPDY: SETTINGS, MAX_CONCURRENT_STREAMS: 10, INITIAL_WINDOW_SIZE: 32768
- Client sends SPDY: SETTINGS, MAX_CONCURRENT_STREAMS: 1000, INITIAL_WINDOW_SIZE: 10485760
- Server initiates closure of TCP connection
- Client sends SPDY: SYN_STREAM (FIN), Stream: 1, Request: GET https://xx.xx.xx.xx/ HTTP/1.1
- Client completes TCP close
Comparing that to a successful transaction (from Chrome on a Mac) shows no differences in SPDY up until the F5 closes the connection from the Android device and replies to the stream request from Chrome.
There are some minor differences in the SSL handshaking, but they both seem to complete without error.
- Markus_WennrichNimbostratus
Update: I decrypted the SSL connection and I see a request within the SPDY connection (too bad, wireshark can't decode SPDY), which the loadbalancer couldn't understand.
Even a "when HTTP_REQUEST { log local0. [HTTP::request] ..." doesn't log anything ...
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com