[
https://issues.apache.org/jira/browse/TS-3474?focusedWorklogId=26122&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26122
]
ASF GitHub Bot logged work on TS-3474:
--------------------------------------
Author: ASF GitHub Bot
Created on: 01/Aug/16 11:26
Start Date: 01/Aug/16 11:26
Worklog Time Spent: 10m
Work Description: Github user atsci commented on the issue:
https://github.com/apache/trafficserver/pull/833
FreeBSD build *failed*! See
https://ci.trafficserver.apache.org/job/Github-FreeBSD/495/ for details.
Issue Time Tracking
-------------------
Worklog Id: (was: 26122)
Time Spent: 2.5h (was: 2h 20m)
> 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: HTTP/2
> Reporter: Sudheer Vinukonda
> Assignee: Masakazu Kitajo
> Fix For: 7.0.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> 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)
