SPDY Server Push support in ATS

I've done some preliminary analysis/prototype of SPDY server push support in ATS, but, ran into a problem with browser (chrome) support for HTTPS cross origin resource push (which is sort of critical in the way, our CDN works). Wanted to open this Jira to share this info with the community and ask for suggestions/opinions.

Basically, there are 3 approaches in supporting Server push at the proxy layer:

• Origin Driven
• Client Driven
• Proxy Driven

Origin Driven approach relies on the origin passing pushable resources as special headers in the response to a base page, for instance. We are exploring making use of the HTTP LINK header for this purpose. The proxy would basically initiate PUSH streams to the client for the resources identified by the LINK headers in the base page response and at the same time, fetch those resources by initiating internal SPDY requests. There are a few things to consider such as whether the pushable resources should be limited to only cacheable resources? Whether non-https resources can be pushed on a https connection, vice-versa etc.

Client Driven approach relies on the Referrer header sent by the client and ATS building dynamically a set of associated resources for a given base page request url. Once such a list is built, the rest of the mechanism is similar to the Origin driven approach.

Proxy Driven approach is mainly for proto-typing purpose and relies on the proxy extracting/unzipping/parsing the response body and identifying pushable resources and initiating the push resources similar to the other approaches above. This is performance intensive and will need some optimizations in not having to parse every response, but doing it based on some sort of count/frequency of the access.

I did some prototyping and was able to push resources, but, realized there are some stumbling blocks. For example, Chrome doesn't permit cross origin HTTPS resources to be pushed (even if certs were presented for both the original and push domain). See below email from Chrome indicating that they won't fix this behavior.

https://code.google.com/p/chromium/issues/detail?id=408317

Here's the summary of the response from Chrome:

"It's very much by design that cross-origin HTTPS push streams are being rejected. The central reason is that the session isn't authenticated for the pushed origin.

The specific requirement is also that a push stream match the origin of it's declared associated stream. This is true even of a SPDY session which presented certs & authenticated for both the associated & push origins: you still need to arrange for an associated stream on the origin for which you'd like to push. The --trusted-spdy-proxy flag relaxes this somewhat, in that it allows cross-origin HTTP push streams (but not HTTPS).

The implementation block you point to is indeed where this logic lives.

There aren't any immediate plans to enable cross-origin HTTPS push, though there are continuing conversations about how it might be done. It'd need to be done very carefully.
"