Forum Discussion

Markus_Wennrich's avatar
Markus_Wennrich
Icon for Nimbostratus rankNimbostratus
Jun 02, 2014

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

 

  • 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 ...

     

  • 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.