[ https://issues.apache.org/jira/browse/TS-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sudheer Vinukonda closed TS-3050. --------------------------------- > SPDY Server Push support in ATS > ------------------------------- > > Key: TS-3050 > URL: https://issues.apache.org/jira/browse/TS-3050 > Project: Traffic Server > Issue Type: New Feature > Components: SPDY > Reporter: Sudheer Vinukonda > Assignee: Sudheer Vinukonda > > 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: > {code} > "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. > " > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)