[jira] [Work logged] (TS-3474) HTTP/2 Server Push support in ATS

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TS-3474?focusedWorklogId=26103&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26103 ]

ASF GitHub Bot logged work on TS-3474:
--------------------------------------

                Author: ASF GitHub Bot
            Created on: 31/Jul/16 13:05
            Start Date: 31/Jul/16 13:05
    Worklog Time Spent: 10m 
      Work Description: GitHub user maskit opened a pull request:

    https://github.com/apache/trafficserver/pull/833

    TS-3474: HTTP/2 Server Push support

    This PR adds an experimental API for server push, and an example plugin for it.
    ```c
    void TSHttpTxnServerPush(TSHttpTxn txnp, const char *url, int url_len)
    ````
    The API is experimental because we don't know whether it fits practical use cases yet.
    
    Also, this PR don't add any concrete implementations into ATS core that are used to determine which contents should be pushed with the API.
    
    https://issues.apache.org/jira/browse/TS-3474

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/maskit/trafficserver ts-3474

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/trafficserver/pull/833.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #833
    
----
commit 1a606af5b13120bd031c71cd92c8d29d68bd7d07
Author: Masakazu Kitajo <ma...@apache.org>
Date:   2016-05-31T05:08:34Z

    TS-3474: Add HTTP/2 Server push support

commit 95f32b71a45ce6a5ce066648e6ed24d5a737618f
Author: Masakazu Kitajo <ma...@apache.org>
Date:   2016-05-31T05:09:30Z

    TS-3474: Add an example plugin of server push

----


Issue Time Tracking
-------------------

            Worklog Id:     (was: 26103)
            Time Spent: 10m
    Remaining Estimate: 0h

> 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: 10m
>  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)