I'm having trouble with the server-sent events transport in SignalR when the client is behind a web proxy. From the user's experience, SignalR tries to make the serverSentEvents connection, that fails so 5 seconds later it falls back to longPolling. I'm using Chrome 38 (Firefox 31 ESR also fails to connect with SSE) and have the webSocket transport disabled for other reasons.
Apparently, the proxy is rewriting the HTTP 1.1 Transfer-Encoding chunks (merging two chunks into one). The Notes section of the SSE spec advises "Authors are also cautioned that HTTP chunking can have unexpected negative effects on the reliability of this protocol." So, right now that's my best guess. Oh, and when I put a breakpoint in the SingalR JavaScript client's EventSource message event handler, it never gets hit.
Can anyone confirm that this chunking change is likely the cause of the connection dropping?
Is there any way to disable chunking on the server side just for this transport?
Here's what the TCP response to the GET /signalr/connect request looks like:
as sent from the server:
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Transfer-Encoding: chunked
Content-Type: text/event-stream
Expires: -1
Server: Microsoft-IIS/7.5
X-Content-Type-Options: nosniff
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Wed, 05 Nov 2014 15:49:29 GMT
13
data: initialized
2f
data: {"C":"d-3B309D97-E,1|F,0","S":1,"M":[]}
0
as received by the client:
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Transfer-Encoding: chunked
Content-Type: text/event-stream
Expires: -1
Server: Microsoft-IIS/7.5
X-Content-Type-Options: nosniff
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Wed, 05 Nov 2014 15:49:29 GMT
42
data: initialized
data: {"C":"d-3B309D97-E,1|F,0","S":1,"M":[]}
0
