Oct 13, 2014, 6:50:51 PM10/13/14
to spdy...@googlegroups.com, William Chan, Mitchell DeMarco, Julian Gautier
On Mon, Oct 13, 2014 at 3:42 PM, Fedor Indutny <fe...@indutny.com
> We have one proxy server that terminates all incoming TLS traffic and routes
> connections to the cleartext backends depending on their servername (i.e.
> SNI TLS extension). One of the webpages on that server is doing Cross-Origin
> request to a different subdomain on that server, and this request is
> expected to be routed to another cleartext backend.
> One week ago things were working perfectly, but now it appears that the
> Chromium has employed an optimisation, and is reusing the SPDY connection
> and issuing all requests to different domains using it. This totally breaks
> stuff for us, because the requests are expected to be happening in a
> different connections, but are routed to the same backend right now.
This sounds like normal SPDY connection pooling. In short: when
routing a SPDY request, if an existing connection has a certificate
that covers the target hostname and the IPs for the target hostname
have a non-empty intersection with the IPs for the existing
connection, then the request will be routed down that connection.
This behaviour is long standing but was disabled a couple of months
ago to address an issue. It was reenabled with Chrome 38, which went
stable last week.
In short: SPDY / HTTP/2 request routers need to work at the request
layer. Alternatively, disable SPDY / HTTP/2.