Push-Assets Header Field

As described in , transfer sizes and resource counts continue to increase. While network conditions continue to improve, resulting in lower latencies and increased bandwidth, HTTP/1.1 ( and ) fails to address the underlying problem of resource dependencies and the resulting "waterfall" of blocked requests. HTTP/2 aims to address some of these problems, by way of Streams and Multiplexing, combined with HTTP/2 Server Push . A ruthless combination, addressing "head-of-line blocking" through Multiplexing, and optimistic pre-loading by way of Server Push. Where Server Push begins to fall short is around client state, leaving it up to servers to leverage existing HTTP State Management Mechanism with Cookies, which are not purpose built to solve the problem of resource dependency state. This lack of client state can result in HTTP/2 RST_STREAM, where-in in-flight Server Push Streams will be cancelled, incurring client and server waste. This document aims to address resource dependency state by looking to Caching familiar with existing HTTP/1.1 requests (see and ). By pulling this state data into the request, servers are able to intelligently and responsibly Server Push only missing or outdated resource.

In this document, the key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are to be interpreted as described in BCP 14, RFC 2119 and indicate requirement levels for compliant implementations. This document uses the Augmented BNF defined in .

Often the most import visit to a site is the first. Push-Assets provides the necessary client state for the server to confidently know which resources are missing or outdated.

As users navigate to previously visited resources, or new resources where some shared resources have been cached, Push-Assets provides the necessary client state to make efficient use of Server Push, only sending what resources the client does not already have.

On one end of the spectrum of proxies lies your server proxies, with CDN's on the other end. With Push-Assets providing efficient communication between two points, this may lend to potential benefits between Proxies and their Origin server as well. While the Proxy nearest your Client SHOULD support Push-Assets for best results, it MAY elect not to also leverage Push-Assets between the Proxy and Origin. For proxies with caching nearest to Client (namely CDN's), they may further benefit from Push-Assets by way of efficient use of Server Push.

By enabling Push-Assets between any two points, Server Push can be used to reduce waste and provide improved performance. The greater the shared resources, the greater the potential benefits.

With Push-Assets being nothing more than an HTTP Header, extending the benefits to other Content Type's is entirely up to the Client and Server. Consider circumstances where you retrieve a JSON resource, which signals relationships with other resources. Push-Assets reduces waste and enables better user experiences irrespective of Content-Type.

A request header field SHALL be sent by the client when requesting the server to support Push-Assets. Comprised of zero or more resources addressed by their Asset-Key. An Asset-Key is the name of the resource uniquely identifiable by the resource or matching resources.

Caching MAY include an etag, and/or last-modified, or no-push. This provides necessary client state of dependencies to server.

Where * informs server to Server Push all push-enabled dependencies, if Push-Assets is enabled. Servers MUST push all missing or outdated push-enabled resources.

A PUSH_PROMISE response Header field MAY be sent to inform the client that the resource should be tracked as a Push-Asset. The Asset-Key MUST be stored in the header field as an MD5 representation of the desired Key. Unlike the Asset-Key in a request, the Push-Asset-Key header field corresponds to the Key of the PUSH_PROMISE response.

By naming a resource, you MAY share that resource across multiple resources, and MAY change the URI as necessary without resulting in wasted requests.

Where $ is reserved as a short-hand for the client to recognize the key as the URI Path , and MUST NOT include the query string. Example URI Path of /my/resource?some=thing would by keyed as /my/resource. If there are more than one cached resources on the client for a given Push-Asset-Key, the client MUST treat the most recent Key as the current version.

An OPTIONAL PUSH_PROMISE response header field. An Asset-Match supports the lexical matching of the URI Path , and MAY end with reserved wildcard * to indicate matching all requests "equal or greater than" the URI Path. While one or more Asset-Path's may be provided, they SHOULD be consistent between requests to avoid any caching proxies from serving varying responses. Usage of Vary header field (Section 7.1.4 of ) MAY be applied with Push-Asset-Match to permit varying responses, but SHOULD NOT be used in most scenarios to avoid unnecessary complexity.

Where all requests with URI Path greater than or equal to /some-path/ will be matched.

* is reserved to indicate "match all requests". This is the equivalent of /*, matching all from root.

State management can be simple for simple origins, but complex for complex origins. Following is a set of usage scenarios and suggested tactics to combat unnecessary waste.

Not uncommon amongst websites are changes to the URI Path of a resource when contents change. For these assets, utilizing the default Push-Asset-Key of $ MAY result in excessive waste by way of the client sending state of matching resources that are no longer applicable. An effective measure is to leverage a uniquely named Push-Asset-Key, enabling the client and server to understand that the resource has effectively been renamed.

Leveraging the power of the Push-Asset-Match header field MAY greatly improve the efficiency of resources shared amongst many resources. If used excessively where-in many requests do not depend on the matched resource MAY lead to waste, as the state of matching resources are sent via Push-Assets header field. The server MAY improve effectiveness by way of highly specific Push-Asset-Match definitions, breaking an origin into multiple sub-paths to permit parts an Origin to operate without negative affect from other parts of Origin. For example, /some-path/ does NOT need to use the same shared resources as /some-other-path/, as they MAY NOT know about one another. In cases where even with highly specific Push-Asset-Match do not address excessive matching, the client MAY track historical false positives where-in matching resources are not served from requested resources, and MAY determine a threshold from which the client MAY elect NOT to send alongside Push-Assets requests.

With Push-Assets not being specific to html resources, clients MUST NOT match resources across requests with varying Content Type's . If a server has enabled Push-Assets for more than one Content Type, the client MUST only notify the server of matching resources that were from the same Content Type of the parent resource. As an example, "/home.html" with a dependent resource that matches all URI Paths, MUST NOT be sent via Push-Assets when making a request for "/file.js" as the parent resources differ in Content Type.