HTTP/2 Server Push Use Cases
draft-bishop-httpbis-push-cases-00

Abstract

HTTP/2 defines the wire mechanics of Server Push. Though the mechanics of how a pushed resource is delivered are well-specified, the use cases that describe which resources can be pushed, in what states, and for what purpose are not described in HTTP/2. As a result, support between implementations varies widely.

This document attempts to enumerate interesting scenarios, in hopes that a more concrete taxonomy can assist the community in arriving at a standard set of supported scenarios.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on December 31, 2018.

Copyright Notice

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Types of Resources
• 2.1. Browser Scenarios
• 2.1.1. Static DOM contents
• 2.1.2. Updated DOM contents
• 2.1.3. Requests made by local script execution
• 2.2. Non-Browser Scenarios
• 2.2.1. Subsequent API Requests
• 2.2.2. Streaming APIs
• 3. Types of Pushes
• 3.1. Pre-Satisfying Requests
• 3.2. Cache Population
• 3.3. Cache Revalidation
• 3.4. Cache Invalidation
• 4. Security Considerations
• 5. Informative References
• Author's Address

1. Introduction

HTTP is fundamentally a request/response mechanism. Each request specifies some action (often content retrieval) which the user agent wishes the server to perform on a resource and return the result of the action.

However, when a response triggers a subsequent request, network and processing delays cause this subsequent request not to begin immediately. The client must receive the initial response (0.5 RTT network delay), parse it and identify the next request (implementation- and page-dependent), then send the request back to the server (0.5 RTT network delay) before the server can begin to satisfy the request.

Some mechanisms attempt to reduce the client processing time by enumerating important follow-up requests in HTTP headers or at the beginning of the response payload. However, these techniques still incur at least 1 RTT of network delay before the server receives the subsequent request. Depending on the distance between client and server, this delay might be significant.

HTTP/2 defines Server Push, a paradigm in which the server can also return the results of actions the user agent did not request. In order to preserve the request-response semantics of HTTP, the server first “promises” something by supplying the request to which it will later provide a response as if the user agent had made the supplied request. Push is also restricted to methods which are defined to be safe and cacheable. (Though the response itself need not be cacheable.)

A push is always associated directly with a client-generated request. No chaining is permitted (a push cannot be associated with another push), nor can a push be promised after the client-initiated stream has closed, though a promised push can be fulfilled at any subsequent time.

This document is an attempt to enumerate categories of resources and situations in which a server might choose to push a resource.

2. Types of Resources

2.1. Browser Scenarios

The most visible use case for HTTP is the web browser. Because a web page is composed of a large number of resources, often spread across different domains, browsers issue a complex series of requests in the course of rendering a page. However, because browsers are generating these requests based on the combination of server-supplied content (the initial response) and local state (the contents of the cache, if any), the server is able to partially predict the client’s rendering behavior. Efforts to standardize the download process between clients ([FETCH]) and to supply more information about the local state to the server ([I-D.ietf-httpbis-cache-digest]) will improve the server’s ability to predict such subsequent requests.

However, web pages are increasingly dynamic, and this makes the browser’s job of determining what is logically connected with the initial request more complex.

2.1.1. Static DOM contents

This is almost universally-supported among browsers. If the resource directly references another resource, either via Link headers ([RFC5988]) or via the entity body, almost all browsers will accept a match for this resource served as a push.

Such resources are typically CSS, JavaScript, images, or other elements required for the rendering or functionality of the page.

2.1.2. Updated DOM contents

After the DOM is constructed, it can be locally modified. Some web sites consist of very sparse static content, then rely on the execution of scripts locally to create DOM elements or update existing elements to reference new target resources.

2.1.3. Requests made by local script execution

The locally executed script, rather than updating DOM elements, is also able to directly generate new HTTP requests (typically so that they can populate DOM elements by script). Many sites have expressed use-cases for pre-answering queries their script would generate in response to user action.

For example, the page might contain a list of e-mails, with script populating the contents of the e-mail once the user clicks a list entry. If a site author knows the user is likely to click one of the first three unread e-mails, the contents of those e-mails are reasonable candidates for Server Push.

2.2. Non-Browser Scenarios

Non-browser scenarios can typically be analyzed as an API.

2.2.1. Subsequent API Requests

There is substantial overlap between non-browser scenarios and the in-browser script scenario described in Section 2.1.3. In both cases, the server is predicting subsequent API calls based on where it believes the client is in the process of execution.

If the server can predict subsequent actions, it can pre-satisfy the most likely cases in order to minimize latency.

2.2.2. Streaming APIs

Some APIs do not fit well with the request-response model of HTTP, but are better understood as a subscription to an event or a data stream. Push can be used in this model, as in [RFC8030], by opening a request which never completes and pushing new data to the client as it becomes available.

Some implementations of push do not make incoming push streams available to clients unless the client makes a request for the corresponding URL. As a result, clients and servers implementing this pattern might wish to also use the original request to stream back the resource identifiers which are being pushed.

3. Types of Pushes

In addition to pushing different resources, push can be delivered in different ways and for different purposes.

3.1. Pre-Satisfying Requests

The most common and most widely supported variety of push simply provides a request that the client is expected to make, along with a successful (typically 200) response carrying the content.

3.2. Cache Population

Pushing resources into the client cache has been a subject of some controversy. Almost all browsers implement a separate and ephemeral cache of pushed resources and do not allow pushed resources to write directly into the HTTP cache, theoretically as a mitigation against populating the cache with content that will never actually be needed.

However, mechanisms such as Link headers ([RFC5988]) with the rel=preload attribute can cause the browser to request any resource, and these headers are also under the server’s control. As a result, any client that implements Section 3.1 will also enable cache population with one additional step.

3.3. Cache Revalidation

While no user agents are known to support this, a server could hypothetically pre-validate stale items in the client’s cache by pushing a conditional request (If-Not-Match or If-Not-Modified) for a resource it believes is already in the cache and a 304 (Not Modified) response.

Such a push could be consumed directly by the cache (updating the validity of the cached object) or treated as a pre-satisfied request should the cache attempt to revalidate an expired object. The former will tend to extend the lifetime of the cached object on each use, while the latter will not affect the object unless it has expired.

A push which attempts to revalidate content which is no longer cached could be treated equivalently to a preload link, a suggestion that this content might soon be needed. Triggering a follow-up request for the full body might improve performance.

3.4. Cache Invalidation

Alternatively, the server could push an unconditional request for the resource, but use the HEAD method instead of GET. If interpreted appropriately by a user agent, this could revalidate a matching item in the cache, or invalidate an item even if the user agent currently believes the item to be fresh.

4. Security Considerations

There probably are some. The existing mitigations against gratuitous pushes are largely ineffective (see Section 3.2), but clients MUST verify that servers are authoritative for any resources they attempt to push, regardless of the scenario being considered.

5. Informative References

Author's Address