Updating HTTP Caching Policy in Trailers

Internet-Draft	Updating HTTP Caching Policy in Trailers	March 2021
Nottingham & Snell	Expires 8 September 2021	[Page]

1. Introduction

Web content that is "dynamically" generated -- i.e., with the response body streamed by the server to the client as it is created -- is often assumed to be uncacheable. In practice, though, there are some scenarios where caching is beneficial; for example, when a private cache might be able to reuse a personalised, dynamic response for a period, or when such a response can be shared by a number of clients.¶

A server choosing a caching policy for such a response faces a conundrum: if an error or other unforeseen condition happens during the generation of the response, that caching policy might be too liberal. Currently, the only available solutions are to:¶

prevent or severely curtail downstream caching, or¶
buffer the response until a caching policy can be confidently assigned.¶

In both cases, performance suffers; in the former, caching efficiency is less than it could be in the common case, In the latter, the server consumes additional resources and delays the response.¶

This specification provides a third solution: updating the caching policy in HTTP trailer fields, after the content has been sent. Doing so allows content to be streamed, while caching policy can be determined after the content is actually generated.¶

1.1. Notational Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

2. The "trailer-update" HTTP Cache Directive

The "trailer-update" cache response directive indicates that the caching policy for that response (as indicated by the header field that contains the directive) might be updated by a corresponding trailer field.¶

When it is present as a cache directive in a header field and a trailer field with the same field name is received, a cache that implements this specification MUST completely replace the stored header field value for that response with the trailer field's value, MUST update its handling of that response to account for the new field value (after any outstanding requests are satisfied), and MUST use that value for the header field in responses to future requests satisfied from that cache entry (i.e., the trailer field is "promoted" to a header field).¶

In responses where the trailer field value has replaced the header field value, the "trailer-update" directive will have been removed as part of that process. Note that the presence of "trailer-update" does not guarantee that a trailer field will follow.¶

Caches MAY temporarily store a response that has a caching policy with both the "no-store" and "trailer-update" directives, but MUST NOT reuse that response until the caching policy is updated in a manner that allows it. If the caching policy is not updated or the "no-store" directive is still present in the updated response, the cache MUST immediately and permanently discard the temporarily stored response.¶

For purposes of calculating a stored response's age ([I-D.ietf-httpbis-cache], Section 4.2.3), caches receiving such a trailer SHOULD consider the response_time to be when the trailer is received, but only when calculating resident_time (not response_delay, as that would be counterproductive for the purpose of estimating network delay).¶

2.1. Examples

Given a resource that supports this specification but encounters no errors in the generation of a response's content, that response might look like this:¶

HTTP/1.1 200 OK
Content-Type: text/html
Cache-Control: max-age=3600, trailer-update

[body]

Caches that do not implement this specification will cache it by the header policy; caches that do implement will see no updates in the trailer and do the same.¶

If a change in caching policy is encountered during the generation of the response content, the resource can prevent reuse by caches that implement this specification by sending:¶

HTTP/1.1 200 OK
Content-Type: text/html
Cache-Control: max-age=3600, trailer-update

[body]
Cache-Control: no-store

In this case, caches that do not implement this specification will again act as instructed by the header policy, but caches that do implement will see the update in the trailers and prevent reuse of the response after the trailer is received (although it might have been used to satisfy requests that were received in the meantime).¶

If a resource wishes to prevent non-implementing caches from storing the response, they can send:¶

HTTP/1.1 200 OK
Content-Type: text/html
Cache-Control: no-store; trailer-update

[body]
Cache-Control: max-age=3600

Here, a non-implementing cache will only see "no-store", and so will not store the response. An implementing cache can optimistically store the response based upon "trailer-update", but only allow its reuse after the caching policy is updated to something which permits that in trailers.¶

Note that when a downstream cache does not implement this specification, and also does not forward a message's trailer section (as allowed by HTTP), any updates will effectively be lost, even if further downstream caches do implement.¶

Updating HTTP Caching Policy in Trailers

Abstract

Note to Readers

Status of This Memo

Copyright Notice

Table of Contents

1. Introduction

1.1. Notational Conventions

2. The "trailer-update" HTTP Cache Directive

2.1. Examples

3. IANA Considerations

4. Security Considerations

5. Normative References

Authors' Addresses