[
https://issues.apache.org/jira/browse/TS-3474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15345324#comment-15345324
]
Kit Chan commented on TS-3474:
------------------------------
Here is my test environment. I apply the patch against a relatively new commit
- d48b76e03fc0d99b144ff3a2276610d75b274899
I used nghttp against my test environment. It does not work initially till i
comment out the following check in Http2ConnectionState.c
{code}
if (client_settings.get(HTTP2_SETTINGS_ENABLE_PUSH) == 0)
{
return;
}
{code}
After that it seems to be doing pretty well. A few questions
1) I am not too sure why the above check will fail. Will do a bit more digging.
But if you know already why, please let me know.
2) I think the API (TSHttpPush) should check if the underlying connection is h2
or not. i think, through checking the plugin_tag
3) On that note, I wonder whether we should just add another API to check the
plugin tag so the plugin can also do their own check if needed. I think that's
mentioned in TS-2987 already but not yet done.
4) Perhaps we should provide the length of the url in the api (TSHttpPush)
instead of assuming the string is null terminated.
5) I think TSHttpTxnServerPush is a better name for the API. What do you think?
> 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
> 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)
