We do not expect SPDY to be used, no. The expected behavior is HTTP on TLS with JSON-RPC payloads (POST/response body).
Perhaps I'm not reading something right here: Looking at #61 in Wireshark, I see the following: 61 16.127749 10.3.2.74 10.1.1.93 TLSv1 279 Application Data TLSv1 Record Layer: Application Data Protocol: http Content Type: Application Data (23) Version: TLS 1.0 (0x0301) Length: 208 Encrypted Application Data: 45c2e557bb7e9146002c5e1041c5843c7f6943856cd7ca37... With server keys in place, data from above is decoded as: 0000 48 54 54 50 2f 31 2e 30 20 34 30 30 20 42 61 64 HTTP/1.0 400 Bad 0010 20 72 65 71 75 65 73 74 0d 0a 43 61 63 68 65 2d request..Cache- 0020 43 6f 6e 74 72 6f 6c 3a 20 6e 6f 2d 63 61 63 68 Control: no-cach 0030 65 0d 0a 43 6f 6e 6e 65 63 74 69 6f 6e 3a 20 63 e..Connection: c 0040 6c 6f 73 65 0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 lose..Content-Ty 0050 70 65 3a 20 74 65 78 74 2f 68 74 6d 6c 0d 0a 0d pe: text/html... 0060 0a 3c 68 74 6d 6c 3e 3c 62 6f 64 79 3e 3c 68 31 .<html><body><h1 0070 3e 34 30 30 20 42 61 64 20 72 65 71 75 65 73 74 >400 Bad request 0080 3c 2f 68 31 3e 0a 59 6f 75 72 20 62 72 6f 77 73 </h1>.Your brows 0090 65 72 20 73 65 6e 74 20 61 6e 20 69 6e 76 61 6c er sent an inval 00a0 69 64 20 72 65 71 75 65 73 74 2e 0a 3c 2f 62 6f id request..</bo 00b0 64 79 3e 3c 2f 68 74 6d 6c 3e 0a dy></html>. On Mon, Feb 23, 2015 at 10:52 AM, Julien Vehent <jul...@linuxwall.info> wrote: > The TLS handshake is working fine. The issue is that HAProxy is trying to > speak SPDY > with your clients, and they most likely don't support it. > > In the Haproxy_1 capture, look at packet #61 send by haproxy to the client. > The application > data protocol is set to SPDY. Is this the expected behavior of your > endpoint? > > - Julien
