SPDY + CORS

[Fedor Indutny]

Hello Spdy Devs, William!

I think I have found an edge case while trying to figure out my company's website issue. The situation is following (sorry for a long intro).

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.

Please let me know if you want to see a test case that reproduces the problem. I'll submit the url privately over email.

Thank you very much for your help!

Fedor.

[Adam Langley]

On Mon, Oct 13, 2014 at 3:42 PM, Fedor Indutny <fe...@indutny.com> wrote:
> 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.

See https://http2.github.io/http2-spec/index.html#reuse

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.


Cheers

AGL

[Fedor Indutny]

Adam,

Am I right that sending 421 response will make chromium re-request? Or is it an HTTP2-only feature?

If this is a HTTP2 thing - I'd suggest doing the same in SPDY.

Cheers,

Fedor.

--

---
You received this message because you are subscribed to the Google Groups "spdy-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spdy-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alexey Baranov]

AFAIK chromium does not yet support 421 response codes (this response code even not defined in response code list yet:)).

When it will, I guess spdy will get this behavior as well, since spdy/h2 is handled by almost the same code in chromium, unless someone will intentionally make session reuse code conditional on SPDY version :)

 

The most dumb fix is to have 2 different certificates I guess.

 

14.10.2014, 03:01, "Fedor Indutny" <fe...@indutny.com>:

[Fedor Indutny]

Alexey,

This is something that we could consider indeed. But 421 code would probably be much more preferable for obvious reasons :)

Cheers,

Fedor.