Push-Assets Header FieldGoDaddyasilvas@godaddy.com
General
Internet-DraftPushPush-Assets is a header field that provides the necessary client state in order for
servers to utilize HTTP/2 Server Push with confidence in knowing
what resources SHOULD or SHOULD NOT be sent, reducing waste, and ultimately providing an
improved user experience. This document will provide an overview of Push-Assets requirements,
and describes any implementation concerns.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.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.Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Augmented BNF for Syntax Specifications: ABNFInternet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]Hypertext Transfer Protocol Version 2 (HTTP/2)This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients.This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.Hypertext Transfer Protocol (HTTP/1.1): CachingThe Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.Hypertext Transfer Protocol (HTTP/1.1): Semantics and ContentThe Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.Uniform Resource Identifier (URI): Generic SyntaxA Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and RoutingThe Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.HTTP State Management MechanismThis document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 2965. [STANDARDS-TRACK]Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message BodiesThis initial document specifies the various headers used to describe the structure of MIME messages. [STANDARDS-TRACK]High Performance Browser Networking