Leif Hedstrom created TS-3474:
---------------------------------
Summary: HTTP/2 Server Push support in ATS
Key: TS-3474
URL: https://issues.apache.org/jira/browse/TS-3474
Project: Traffic Server
Issue Type: New Feature
Components: SPDY
Reporter: Sudheer Vinukonda
Assignee: Sudheer Vinukonda
Fix For: sometime
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)
