[
https://issues.apache.org/jira/browse/TS-3474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14389248#comment-14389248
]
Brian Geffon edited comment on TS-3474 at 3/31/15 7:32 PM:
-----------------------------------------------------------
In my opinion the only way server push should happen should be from an origin
returning an X-Associated-Content header, the proxy would then fetch the
content and push it. This is how many other SPDY/HTTP/2 proxies handle this
situation, additionally, it allows existing HTTP/1.1 endpoints to specify
exactly what content should be pushed (This is your case 1, which makes sense).
In TS core I do not believe we should implement any type of optimistic pushing,
this logic must live in a plugin if that's the route we were to take. We would
likely need to expose APIs for HTTP/2 to make this happen.
Regarding your Case 2, I didn't fully understand what you meant by client
initiated sever push...could you clarify what that means or what it would look
like?
was (Author: briang):
In my opinion the only way server push should happen should be from an origin
returning an X-Associated-Content header, the proxy would then fetch the
content and push it. This is how many other SPDY/HTTP/2 proxies handle this
situation, additionally, it allows existing HTTP/1.1 endpoints to specify
exactly what content should be pushed. In TS core I do not believe we should
implement any type of optimistic pushing, this logic must live in a plugin if
that's the route we were to take.
> 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: 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)
