RFC 7234

Hypertext Transfer Protocol (HTTP/1.1): Caching

📅 published June 2014, from ietf

RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching 🦋

  • Who wrote it: Internet Engineering Task Force (IETF) 🌸
  • Authors: R. Fielding, Ed. (Adobe), M. Nottingham, Ed. (Akamai), J. Reschke, Ed. (greenbytes) 💅
  • Category: Standards Track
  • Date: June 2014
  • ISSN: 2070-1721
  • Obsoletes: RFC 2616 ✨ (this one replaces it)
  • Updates: nothing listed in the header

Abstract

okay so HTTP is a stateless application-level protocol for distributed, collaborative, hypertext information systems 🌈 this doc defines HTTP caches and the header fields that control cache behavior or mark cacheable response messages. it's giving organization, no cap 💖

Status of This Memo

This is an Internet Standards Track document. 🎀

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 5741 ✨

Info about the current status, any errata, and how to give feedback is at http://www.rfc-editor.org/info/rfc7234 🧚

Copyright (c) 2014 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 (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions. Code Components pulled from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 💜

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have granted the IETF Trust the right to allow modifications outside the IETF Standards Process. Unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🙈

Table of Contents

   1. Introduction ....................................................4
      1.1. Conformance and Error Handling .............................4
      1.2. Syntax Notation ............................................4
           1.2.1. Delta Seconds .......................................5
   2. Overview of Cache Operation .....................................5
   3. Storing Responses in Caches .....................................6
      3.1. Storing Incomplete Responses ...............................7
      3.2. Storing Responses to Authenticated Requests ................7
      3.3. Combining Partial Content ..................................8
   4. Constructing Responses from Caches ..............................8
      4.1. Calculating Secondary Keys with Vary .......................9
      4.2. Freshness .................................................11
           4.2.1. Calculating Freshness Lifetime .....................12
           4.2.2. Calculating Heuristic Freshness ....................13
           4.2.3. Calculating Age ....................................13
           4.2.4. Serving Stale Responses ............................15
      4.3. Validation ................................................16
           4.3.1. Sending a Validation Request .......................16
           4.3.2. Handling a Received Validation Request .............16
           4.3.3. Handling a Validation Response .....................18
           4.3.4. Freshening Stored Responses upon Validation ........18
           4.3.5. Freshening Responses via HEAD ......................19
      4.4. Invalidation ..............................................20
   5. Header Field Definitions .......................................21
      5.1. Age .......................................................21
      5.2. Cache-Control .............................................21
           5.2.1. Request Cache-Control Directives ...................22
           5.2.2. Response Cache-Control Directives ..................24
           5.2.3. Cache Control Extensions ...........................27
      5.3. Expires ...................................................28
      5.4. Pragma ....................................................29
      5.5. Warning ...................................................29
           5.5.1. Warning: 110 - "Response is Stale" .................31
           5.5.2. Warning: 111 - "Revalidation Failed" ...............31
           5.5.3. Warning: 112 - "Disconnected Operation" ............31
           5.5.4. Warning: 113 - "Heuristic Expiration" ..............31
           5.5.5. Warning: 199 - "Miscellaneous Warning" .............32
           5.5.6. Warning: 214 - "Transformation Applied" ............32
           5.5.7. Warning: 299 - "Miscellaneous Persistent Warning" ..32
   6. History Lists ..................................................32
   7. IANA Considerations ............................................32
      7.1. Cache Directive Registry ..................................32
           7.1.1. Procedure ..........................................32
           7.1.2. Considerations for New Cache Control Directives ....33
           7.1.3. Registrations ......................................33
      7.2. Warn Code Registry ........................................34
           7.2.1. Procedure ..........................................34
           7.2.2. Registrations ......................................34
      7.3. Header Field Registration .................................34
   8. Security Considerations ........................................35
   9. Acknowledgments ................................................36
   10. References ....................................................36
      10.1. Normative References .....................................36
      10.2. Informative References ...................................37
   Appendix A. Changes from RFC 2616 .................................38
   Appendix B. Imported ABNF .........................................39
   Appendix C. Collected ABNF ........................................39
   Index .............................................................41

1. Introduction ✨

HTTP is usually used for distributed information systems, and performance can get a major glow-up with response caches 💖 This document defines the parts of HTTP/1.1 about caching and reusing response messages.

An HTTP cache is a local store of response messages, plus the subsystem that handles storing, retrieving, and deleting those messages 🌸 A cache keeps cacheable responses so future, equivalent requests get answered faster and use less network bandwidth. Any client or server MAY employ a cache 🫶 but a server acting as a tunnel can't use a cache.

A shared cache stores responses so more than one user can reuse them. Shared caches are usually (but not always) part of an intermediary 🦋 A private cache is the opposite, dedicated to a single user, and it's often a component of a user agent 💅

The whole goal of caching in HTTP/1.1 is a big performance boost, made by reusing a prior response to satisfy a current request 🔥 A stored response is "fresh" (see Section 4.2) if it can be reused without "validation", which means checking with the origin server to see if the cached response is still valid for this request. A fresh response cuts down on both latency and network overhead every time it's reused 😭 When a cached response isn't fresh, it might still be reusable if it can be freshened by validation (Section 4.3), or if the origin is unavailable (Section 4.2.4) 👑

1.1. Conformance and Error Handling

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 🎀

Conformance criteria and error-handling considerations are defined in Section 2.5 of [RFC7230] 💜

1.2. Syntax Notation

This spec uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234], along with a list extension from Section 7 of [RFC7230]. That extension lets you define comma-separated lists compactly with a '#' operator, kind of like how '*' shows repetition 🧚 Appendix B covers the rules imported from other documents. Appendix C shows the full collected grammar with every list operator expanded into standard ABNF notation 🌈

1.2.1. Delta Seconds

The delta-seconds rule is a non-negative integer that represents time in seconds ⭐

  delta-seconds  = 1*DIGIT

A recipient that parses a delta-seconds value and converts it to binary form ought to use an arithmetic type with at least 31 bits of non-negative integer range. If a cache gets a delta-seconds value bigger than the greatest integer it can represent, or if any of its later calculations overflow, the cache MUST consider the value to be either 2147483648 (2^31) or the greatest positive integer it can conveniently represent. 🙈

Note: The value 2147483648 is here for historical reasons. It effectively represents infinity (over 68 years), and it doesn't need to be stored in binary form. An implementation could produce it as a canned string if any overflow happens, even if the calculations use an arithmetic type that can't directly represent that number. What really matters is that an overflow gets detected and isn't treated as a negative value in later calculations 💀

Part 1 of 8 is done, bestie 🦋 Section 2, Overview of Cache Operation, is up next 💖

2. Overview of Cache Operation ✨

Okay bestie, so proper cache operation keeps the semantics of HTTP transfers ([RFC7231]) while cutting out the transfer of info the cache already has 🫶 Caching is totally an OPTIONAL feature of HTTP, but it's safe to assume that reusing a cached response is desirable and is the default unless a requirement or local config says no 🙅‍♀️ So the HTTP cache rules are mostly about stopping a cache from storing a response it shouldn't reuse, or reusing a stored one at the wrong time 💀 They're not about forcing caches to store and reuse specific responses. Main character energy of "don't mess this up," not "store everything" 💅

Each cache entry is a cache key plus one or more HTTP responses from earlier requests that used the same key 🎀 The most common entry is a successful retrieval, aka a 200 (OK) response to a GET request, which holds a representation of the resource named by the request target (Section 4.3.1 of [RFC7231]) 🍓 But caches can also hold permanent redirects, negative results (like 404 (Not Found)), incomplete results (like 206 (Partial Content)), and responses to methods other than GET 🌈 That last one only works if the method's definition allows it and defines something suitable to use as a cache key ✨

The primary cache key is the request method and target URI 🔑 BUT, and this is a lowkey plot twist 👀, HTTP caches today are usually limited to caching GET responses, so lots of them just skip other methods and use only the URI as the primary cache key 💜

If a request target is subject to content negotiation, its cache entry can hold multiple stored responses 🦋 Each one is told apart by a secondary key made from the values of the original request's selecting header fields (Section 4.1) 🧚

3. Storing Responses in Caches 🎀

A cache MUST NOT store a response to any request, unless:

  • The request method is understood by the cache and defined as being cacheable, and
  • the response status code is understood by the cache, and
  • the "no-store" cache directive (see Section 5.2) does not appear in request or response header fields, and
  • the "private" response directive (see Section 5.2.2.6) does not appear in the response, if the cache is shared, and
  • the Authorization header field (see Section 4.2 of [RFC7235]) does not appear in the request, if the cache is shared, unless the response explicitly allows it (see Section 3.2), and
  • the response either:
    • contains an Expires header field (see Section 5.3), or
    • contains a max-age response directive (see Section 5.2.2.8), or
    • contains a s-maxage response directive (see Section 5.2.2.9) and the cache is shared, or
    • contains a Cache Control Extension (see Section 5.2.3) that allows it to be cached, or
    • has a status code that is defined as cacheable by default (see Section 4.2.2), or
    • contains a public response directive (see Section 5.2.2.5).

Note that any of the requirements listed above can be overridden by a cache-control extension; see Section 5.2.3 ✨

In this context, a cache has "understood" a request method or a response status code if it recognizes it and implements all specified caching-related behavior 🧠

Note that, in normal operation, some caches won't store a response that has neither a cache validator nor an explicit expiration time, since those usually aren't useful to store 🙈 Caches are not prohibited from storing them, though 🤷‍♀️

3.1. Storing Incomplete Responses 🌸

A response message counts as complete when all of the octets indicated by the message framing ([RFC7230]) are received before the connection is closed 💖 If the request method is GET, the response status code is 200 (OK), and the entire response header section has been received, a cache MAY store an incomplete response message body if the cache entry is recorded as incomplete 🫧 Likewise, a 206 (Partial Content) response MAY be stored as if it were an incomplete 200 (OK) cache entry 🦋 But a cache MUST NOT store incomplete or partial-content responses if it doesn't support the Range and Content-Range header fields, or if it doesn't understand the range units used in those fields 🚫

A cache MAY complete a stored incomplete response by making a later range request ([RFC7233]) and combining the successful response with the stored entry, as defined in Section 3.3 🧩 A cache MUST NOT use an incomplete response to answer requests unless the response has been made complete, or the request is partial and specifies a range that is wholly within the incomplete response 😭 And a cache MUST NOT send a partial response to a client without explicitly marking it as such using the 206 (Partial Content) status code 🎀

3.2. Storing Responses to Authenticated Requests 🔐

A shared cache MUST NOT use a cached response to a request with an Authorization header field (Section 4.2 of [RFC7235]) to satisfy any later request, unless a cache directive that allows such responses to be stored is present in the response 🙅‍♀️

In this specification, the following Cache-Control response directives (Section 5.2.2) have that effect: must-revalidate, public, and s-maxage 💜

Note that cached responses containing the "must-revalidate" and/or "s-maxage" response directives are not allowed to be served stale (Section 4.2.4) by shared caches 🛑 In particular, a response with either "max-age=0, must-revalidate" or "s-maxage=0" can't be used to satisfy a later request without revalidating it on the origin server 🙃

3.3. Combining Partial Content 🧁

A response might only transfer part of a representation, if the connection closed early or if the request used one or more Range specifiers ([RFC7233]) 🫠 After several of these transfers, a cache might have several ranges of the same representation 🧩 A cache MAY combine these ranges into a single stored response, and reuse that response to satisfy later requests, if they all share the same strong validator and the cache complies with the client requirements in Section 4.3 of [RFC7233] ✨

When combining the new response with one or more stored responses, a cache MUST:

  • delete any Warning header fields in the stored response with warn-code 1xx (see Section 5.5);
  • retain any Warning header fields in the stored response with warn-code 2xx; and,
  • use other header fields provided in the new response, aside from Content-Range, to replace all instances of the corresponding header fields in the stored response 🎀

4. Constructing Responses from Caches 🧚

When presented with a request, a cache MUST NOT reuse a stored response, unless:

  • The presented effective request URI (Section 5.5 of [RFC7230]) and that of the stored response match, and
  • the request method associated with the stored response allows it to be used for the presented request, and
  • selecting header fields nominated by the stored response (if any) match those presented (see Section 4.1), and
  • the presented request does not contain the no-cache pragma (Section 5.4), nor the no-cache cache directive (Section 5.2.1), unless the stored response is successfully validated (Section 4.3), and
  • the stored response does not contain the no-cache cache directive (Section 5.2.2.2), unless it is successfully validated (Section 4.3), and
  • the stored response is either:
    • fresh (see Section 4.2), or
    • allowed to be served stale (see Section 4.2.4), or
    • successfully validated (see Section 4.3).

Note that any of the requirements listed above can be overridden by a cache-control extension; see Section 5.2.3 💅

When a stored response is used to satisfy a request without validation, a cache MUST generate an Age header field (Section 5.1), replacing any present in the response with a value equal to the stored response's current_age; see Section 4.2.3 ⏰

A cache MUST write through requests with methods that are unsafe (Section 4.2.1 of [RFC7231]) to the origin server 📮 In other words, a cache is not allowed to generate a reply to such a request before it has forwarded the request and received a corresponding response 🙅‍♀️

Also, note that unsafe requests might invalidate already-stored responses; see Section 4.4 💀

When more than one suitable response is stored, a cache MUST use the most recent response (as determined by the Date header field) 📅 It can also forward the request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to sort out which response to use 🫶

A cache that doesn't have a clock available MUST NOT use stored responses without revalidating them upon every use 🕰️

4.1. Calculating Secondary Keys with Vary 🔑

When a cache receives a request that can be satisfied by a stored response with a Vary header field (Section 7.1.4 of [RFC7231]), it MUST NOT use that response unless all of the selecting header fields nominated by the Vary header field match in both the original request (i.e., the one associated with the stored response) and the presented request 🎯

The selecting header fields from two requests are defined to match if and only if the ones in the first request can be transformed into the ones in the second request by applying any of the following:

  • adding or removing whitespace, where allowed in the header field's syntax
  • combining multiple header fields with the same field name (see Section 3.2 of [RFC7230])
  • normalizing both header field values in a way that is known to have identical semantics, according to the header field's specification (e.g., reordering field values when order is not significant; case-normalization, where values are defined to be case-insensitive)

If a header field is absent from a request (after any normalization that might happen), it can only match another request if it's also absent there 🫥

A Vary header field-value of "*" always fails to match 🚫

The stored response with matching selecting header fields is known as the selected response 🏆

If multiple selected responses are available (potentially including responses without a Vary header field), the cache will need to pick one 🤔 When a selecting header field has a known mechanism for doing so (e.g., qvalues on Accept and similar request header fields), that mechanism MAY be used to select preferred responses 🌈 Of the remainder, the most recent response (as determined by the Date header field) is used, as per Section 4 ✨

If no selected response is available, the cache cannot satisfy the presented request 😔 Typically, it's forwarded to the origin server in a request that may be conditional (see Section 4.3) 💜

4.2. Freshness 🦋

okay so a fresh response is one whose age hasn't gone over its freshness lifetime yet 💅 and a stale one is the opposite, the age HAS gone over 😭

the freshness lifetime is just the time between when the origin server made the response and when it expires ⏰ an explicit expiration time is the origin server saying "don't reuse this without checking with me first" 🫶 and a heuristic expiration time is when a cache makes one up because there wasn't an explicit one 🤷‍♀️

the age is how long it's been since the origin server generated the response, or since it was successfully validated with them 🌸

when a response is "fresh" in the cache, it can answer later requests WITHOUT bothering the origin server at all ✨ that's the whole efficiency glow-up 🔥

the main way to figure out freshness is for the origin server to hand over an explicit expiration time in the future, using either the Expires header field (Section 5.3) or the max-age response directive (Section 5.2.2.8) 💜 origin servers usually pick future times because they don't think the representation will change in a semantically significant way before then 🌈

if an origin server wants to force a cache to check EVERY single request, it can set an expiration time in the past so the response is already stale 💀 well-behaved caches will usually validate a stale response before reusing it (see Section 4.2.4) 🙈

origin servers don't always send expiration times, so caches are also allowed to use a heuristic in certain situations (see Section 4.2.2) 🍓

the freshness check is:

response_is_fresh = (freshness_lifetime > current_age)

freshness_lifetime is defined in Section 4.2.1, and current_age is defined in Section 4.2.3 🧚

clients can send the max-age or min-fresh cache directives in a request to tighten or loosen the freshness math for that response (Section 5.2.1) 💖

now, to avoid the classic date parsing drama 😩:

  • Even though all date formats are case-sensitive, a cache recipient SHOULD match day, week, and time-zone names case-insensitively. ✨
  • If a cache recipient's internal time implementation is less precise than an HTTP-date, the recipient MUST internally store a parsed Expires date as the nearest time that is equal to or earlier than the received value. 🫧
  • A cache recipient MUST NOT let local time zones influence the calculation or comparison of an age or expiration time. 🌍🚫
  • A cache recipient SHOULD treat a date with a zone abbreviation other than GMT or UTC as invalid for calculating expiration. 🙅‍♀️
Freshness only matters for cache operation! It can NOT be used to force a user agent to refresh its display or reload a resource. For the difference between caches and history mechanisms, see Section 6. 👀

4.2.1. Calculating Freshness Lifetime 🧮

a cache works out the freshness lifetime (called freshness_lifetime) by using the FIRST of these that matches 🥇:

  • If the cache is shared AND the s-maxage response directive (Section 5.2.2.9) is present, use its value, or
  • If the max-age response directive (Section 5.2.2.8) is present, use its value, or
  • If the Expires response header field (Section 5.3) is present, use its value minus the value of the Date response header field, or
  • Otherwise, there's no explicit expiration time in the response. A heuristic freshness lifetime might apply here; see Section 4.2.2. 🔍

this math is immune to clock skew, since all of the info comes straight from the origin server 🕰️✨

if a directive shows up more than once (like two Expires header fields, or multiple Cache-Control: max-age directives), that directive's value is considered invalid 😵 caches are encouraged to treat responses with invalid freshness info as stale 🫠

4.2.2. Calculating Heuristic Freshness 🔮

since origin servers don't always send explicit expiration times, a cache MAY assign a heuristic expiration time when there isn't an explicit one, using algorithms that look at other header field values (like the Last-Modified time) to guess a believable expiration time 🎲 this spec doesn't give any specific algorithms, but it DOES put worst-case limits on what they can produce 🚧

a cache MUST NOT use heuristics to decide freshness when the stored response has an explicit expiration time 🙅‍♀️ because of the rules in Section 3, this basically means heuristics only work on responses with no explicit freshness whose status codes are cacheable by default (see Section 6.1 of [RFC7231]), plus responses without explicit freshness that have been explicitly marked cacheable (for example, with a "public" response directive) 💜

if the response has a Last-Modified header field (Section 2.2 of [RFC7232]), caches are encouraged to pick a heuristic expiration value that's no more than some fraction of the time since then 📅 a typical fraction might be 10% 🍰

when a heuristic is used to calculate freshness lifetime, a cache SHOULD add a Warning header field with a 113 warn-code (see Section 5.5.4) to the response if its current_age is more than 24 hours AND no such warning is already there ⚠️🫶

Note: Section 13.9 of [RFC2616] stopped caches from calculating heuristic freshness for URIs with query components (i.e., ones containing '?'). In practice, this hasn't been widely implemented 🙃 so origin servers are encouraged to send explicit directives (for example, Cache-Control: no-cache) if they want to stop caching. 🛑💅

4.2.3. Calculating Age ⏳

the Age header field conveys the estimated age of a response message when it comes from a cache 🎀 its value is the cache's estimate of the number of seconds since the origin server generated or validated the response 🕐 basically, the Age value is the sum of the time the response has been sitting in each cache along the path from the origin server, plus the time it's spent traveling over network paths 🛤️✨

here's the data used for the age calculation 📝:

  • age_value: the value of the Age header field (Section 5.1), in a form you can do math with; or 0 if it's not available. 🔢
  • date_value: the value of the Date header field, in a form you can do math with. See Section 7.1.1.2 of [RFC7231] for the definition of the Date header field, and for the rules on responses that don't have one. 📆
  • now: "the current value of the clock at the host performing the calculation." A host ought to use NTP ([RFC5905]) or a similar protocol to sync its clocks to Coordinated Universal Time. ⏱️🌐
  • request_time: the current value of the clock at the host when the request that produced the stored response was made. 📤
  • response_time: the current value of the clock at the host when the response was received. 📥

a response's age can be worked out in two totally independent ways 🧠

  1. the "apparent_age": response_time minus date_value, if the local clock is reasonably well synced with the origin server's clock. If the result is negative, it gets replaced by zero. 🫧
  2. the "corrected_age_value", if ALL of the caches along the response path implement HTTP/1.1. A cache MUST interpret this value relative to the time the request was initiated, NOT the time the response was received. ⏪
apparent_age = max(0, response_time - date_value);

response_delay = response_time - request_time;
corrected_age_value = age_value + response_delay;

these get combined like this 🤝

corrected_initial_age = max(apparent_age, corrected_age_value);

...unless the cache is confident in the Age header field's value (for example, because there are no HTTP/1.0 hops in the Via header field). In that case, the corrected_age_value MAY be used as the corrected_initial_age. 🎯

the current_age of a stored response can then be calculated by adding the time (in seconds) since the stored response was last validated by the origin server to the corrected_initial_age 🧁

resident_time = now - response_time;
current_age = corrected_initial_age + resident_time;

4.2.4. Serving Stale Responses 🥀

a "stale" response is one that either has explicit expiry info or is allowed to have a heuristic expiry calculated, but isn't fresh according to the math in Section 4.2 🙃

a cache MUST NOT generate a stale response if an explicit in-protocol directive prohibits it (for example, a "no-store" or "no-cache" cache directive, a "must-revalidate" cache-response-directive, or an applicable "s-maxage" or "proxy-revalidate" cache-response-directive; see Section 5.2.2) 🚫

a cache MUST NOT send stale responses UNLESS it's disconnected (meaning it can't contact the origin server or otherwise find a forward path) or doing so is explicitly allowed (for example, by the max-stale request directive; see Section 5.2.1) 🔌

a cache SHOULD add a Warning header field with the 110 warn-code (see Section 5.5.1) to stale responses 🫣 likewise, a cache SHOULD add a 112 warn-code (see Section 5.5.3) to stale responses if the cache is disconnected 📴

a cache SHOULD NOT generate a new Warning header field when forwarding a response that doesn't have an Age header field, even if it's already stale 🙅‍♀️ and a cache doesn't need to validate a response that only became stale in transit 🚌✨

4.3. Validation 🤝

when a cache has one or more stored responses for a requested URI but can't serve any of them (for example, because they're not fresh, or none can be selected; see Section 4.1), it can use the conditional request mechanism [RFC7232] in the forwarded request 💌 this gives the next inbound server a chance to pick a valid stored response to use (updating the stored metadata in the process), or to replace the stored response(s) with a new one 🔄 this whole process is called "validating" or "revalidating" the stored response 💅🦋

4.3.1. Sending a Validation Request 💌

okay so when a cache wants to send a conditional request to check if its stored stuff is still good, it attaches one or more precondition header fields carrying validator metadata from its stored response(s). The recipients compare those to figure out whether a stored response is equivalent to a current representation of the resource. 🫶

One validator is the timestamp from a Last-Modified header field (Section 2.2 of [RFC7232]). This can go in an If-Modified-Since header field for response validation, or in an If-Unmodified-Since or If-Range header field for representation selection. That second one is giving "the client is talking about one specific representation they already got with that timestamp" 🕰️

Another validator is the entity-tag in an ETag header field (Section 2.3 of [RFC7232]). One or more entity-tags, each pointing at a stored response, can go in an If-None-Match header field for response validation. They can also go in an If-Match or If-Range header field for representation selection, which means the client is referring to one or more representations it already has, by those exact entity-tags. 🏷️✨

4.3.2. Handling a Received Validation Request 🎀

Each client in the request chain may have its own cache, so it's super common for a cache at an intermediary to get conditional requests from other (outbound) caches. 🌸 Also, some user agents use conditional requests to keep data transfers small by only grabbing recently modified representations, or to finish downloading a partially retrieved representation. 🧚

If a cache gets a request that can be satisfied by reusing one of its stored 200 (OK) or 206 (Partial Content) responses, the cache SHOULD evaluate any applicable conditional header field preconditions received in that request with respect to the corresponding validators contained within the selected response. 🔍

A cache MUST NOT evaluate conditional header fields that are only applicable to an origin server. That also covers ones found in a request whose semantics can't be satisfied with a cached response, and ones applied to a target resource it has no stored responses for. Those preconditions are likely meant for some other (inbound) server, so hands off 🙅‍♀️

The proper evaluation of conditional requests by a cache depends on the received precondition header fields and their precedence, as defined in Section 6 of [RFC7232]. Also, the If-Match and If-Unmodified-Since conditional header fields are not applicable to a cache. Not for her 💅

A request containing an If-None-Match header field (Section 3.2 of [RFC7232]) means the client wants to validate one or more of its own stored responses against whichever stored response the cache selected. If the field-value is *, or if it's a list of entity-tags and at least one of them matches the entity-tag of the selected stored response, a cache recipient SHOULD generate a 304 (Not Modified) response (using the metadata of the selected stored response) instead of sending that stored response. Main character energy, no duplicates needed 👑

When a cache decides to revalidate its own stored responses for a request that has an If-None-Match list of entity-tags, the cache MAY combine the received list with a list of entity-tags from its own stored set of responses (fresh or stale). Then it sends the union of the two lists as a replacement If-None-Match field value in the forwarded request. 🧩 If a stored response contains only partial content, the cache MUST NOT include its entity-tag in the union unless the request is for a range that would be fully satisfied by that partial stored response. If the response to the forwarded request is 304 (Not Modified) and has an ETag header field value with an entity-tag that is not in the client's list, the cache MUST generate a 200 (OK) response for the client. It does that by reusing its corresponding stored response, as updated by the 304 response metadata (Section 4.3.4). 🫠➡️🥰

If there's no If-None-Match header field, a request containing an If-Modified-Since header field (Section 3.3 of [RFC7232]) means the client wants to validate one or more of its own stored responses by modification date. A cache recipient SHOULD generate a 304 (Not Modified) response (using the metadata of the selected stored response) if one of the following cases is true:

  • 1) the selected stored response has a Last-Modified field-value that is earlier than or equal to the conditional timestamp;
  • 2) no Last-Modified field is present in the selected stored response, but it has a Date field-value that is earlier than or equal to the conditional timestamp; or,
  • 3) neither Last-Modified nor Date is present in the selected stored response, but the cache recorded it as having been received at a time earlier than or equal to the conditional timestamp.

A cache that implements partial responses to range requests, as defined in [RFC7233], also needs to evaluate a received If-Range header field (Section 3.2 of [RFC7233]) with respect to its selected stored response. ✂️

4.3.3. Handling a Validation Response 🤔

Cache handling of a response to a conditional request depends on its status code:

  • A 304 (Not Modified) response status code means the stored response can be updated and reused. See Section 4.3.4. 🥳
  • A full response (i.e., one with a payload body) means none of the stored responses nominated in the conditional request is suitable. In that case, the cache MUST use the full response to satisfy the request and MAY replace the stored response(s). 🔄
  • However, if a cache receives a 5xx (Server Error) response while attempting to validate a response, it can either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, the cache MAY send a previously stored response (see Section 4.2.4). 😬

4.3.4. Freshening Stored Responses upon Validation ✨

When a cache receives a 304 (Not Modified) response and already has one or more stored 200 (OK) responses for the same cache key, it needs to figure out which of those stored responses are updated by this new response. Then it updates them with the new info from the 304 response. 🍓

The stored response to update is identified by using the first match (if any) of the following:

  • If the new response contains a strong validator (see Section 2.1 of [RFC7232]), then that strong validator identifies the selected representation for update. All of the stored responses with the same strong validator are selected. If none of the stored responses contain the same strong validator, then the cache MUST NOT use the new response to update any stored responses. 🚫
  • If the new response contains a weak validator and that validator corresponds to one of the cache's stored responses, then the most recent of those matching stored responses is selected for update. 🫧
  • If the new response does not include any form of validator (such as when a client generates an If-Modified-Since request from a source other than the Last-Modified response header field), and there is only one stored response, and that stored response also lacks a validator, then that stored response is selected for update. 🤷‍♀️

If a stored response is selected for update, the cache MUST:

  • delete any Warning header fields in the stored response with warn-code 1xx (see Section 5.5);
  • retain any Warning header fields in the stored response with warn-code 2xx; and,
  • use other header fields provided in the 304 (Not Modified) response to replace all instances of the corresponding header fields in the stored response. 🔁

4.3.5. Freshening Responses via HEAD 🦋

A response to the HEAD method is identical to what an equivalent request made with a GET would have been, except it lacks a body. 🙈 This property of HEAD responses can be used to invalidate or update a cached GET response if the more efficient conditional GET request mechanism is not available (due to no validators being present in the stored response). It can also be used if transmission of the representation body is not desired, even if it has changed.

When a cache makes an inbound HEAD request for a given request target and receives a 200 (OK) response, the cache SHOULD update or invalidate each of its stored GET responses that could have been selected for that request (see Section 4.1). 💫

For each of the stored responses that could have been selected, if the stored response and HEAD response have matching values for any received validator fields (ETag and Last-Modified) and, if the HEAD response has a Content-Length header field, the value of Content-Length matches that of the stored response, the cache SHOULD update the stored response as described below. Otherwise, the cache SHOULD consider the stored response to be stale. 🥹

If a cache updates a stored response with the metadata provided in a HEAD response, the cache MUST:

  • delete any Warning header fields in the stored response with warn-code 1xx (see Section 5.5);
  • retain any Warning header fields in the stored response with warn-code 2xx; and,
  • use other header fields provided in the HEAD response to replace all instances of the corresponding header fields in the stored response, and append new header fields to the stored response's header section unless otherwise restricted by the Cache-Control header field. 🧁

4.4. Invalidation 💥

Because unsafe request methods (Section 4.2.1 of [RFC7231]) such as PUT, POST or DELETE have the potential to change state on the origin server, intervening caches can use them to keep their contents up to date. It's giving "clear the old stuff so nobody gets served tea from last week" 🍵

A cache MUST invalidate the effective Request URI (Section 5.5 of [RFC7230]), as well as the URI(s) in the Location and Content-Location response header fields (if present), when a non-error status code is received in response to an unsafe request method. 🧹

However, a cache MUST NOT invalidate a URI from a Location or Content-Location response header field if the host part of that URI differs from the host part in the effective request URI (Section 5.5 of [RFC7230]). This helps prevent denial-of-service attacks. 🛡️😭

A cache MUST invalidate the effective request URI (Section 5.5 of [RFC7230]) when it receives a non-error response to a request with a method whose safety is unknown. ⚠️

Here, a "non-error response" is one with a 2xx (Successful) or 3xx (Redirection) status code. "Invalidate" means that the cache will either remove all stored responses related to the effective request URI, or will mark them as "invalid" and in need of a mandatory validation before they can be sent in response to a subsequent request. 📝

Note that this does not guarantee that all appropriate responses are invalidated. For example, a state-changing request might invalidate responses in the caches it travels through, but relevant responses still might be stored in other caches that it has not. 🙃

5. Header Field Definitions 🎀

This section defines the syntax and semantics of HTTP/1.1 header fields related to caching. Let's get into it, bestie 🧚💖

5.1. Age ✨

okay so the Age header is basically the sender going "hey, this response is about this old" 🕰️💖 it's the sender's best guess for how long it's been since the origin server generated the response or last successfully validated it. and the math for those numbers lives in Section 4.2.3, so go check there if you want the full recipe 🧁

Age = delta-seconds

the Age value is a non-negative integer counting seconds (see Section 1.2.1) 🌸

here's the lowkey important bit: if you see an Age header, that tells you the response was NOT generated or validated by the origin server for this particular request 👀 BUT no Age header doesn't mean the origin was contacted, bc the response could've come from an HTTP/1.0 cache that just doesn't do Age at all 🙃

5.2. Cache-Control 🎀

the Cache-Control header is where the directives live, and these are giving main character energy for caches along the request/response chain 💅 they're one-way too, so a directive in a request does NOT mean the same directive shows up in the response, and vice versa 🦋

a cache MUST follow the requirements of the Cache-Control directives in this section 🫶 and for directives defined somewhere else, see Section 5.2.3 for how those get handled 💜

Note: some HTTP/1.0 caches might not implement Cache-Control at all, so don't be shocked if they ignore it 😭

a proxy MUST pass cache directives through in forwarded messages, whether or not it runs a cache itself, and it doesn't matter if it understands what the directive is for 🧚 the reason is that the directive might matter to every recipient down the chain, and you literally can't aim a directive at one specific cache 🎯

cache directives are tokens, compared case-insensitively 🔤 they can have an optional argument, and that argument can be either a token or a quoted-string 🌈 for the directives below that take arguments, recipients ought to accept both forms, even if one of them is the documented favourite 💖 and for any directive this spec doesn't define, a recipient MUST accept both forms 🍓

Cache-Control   = 1#cache-directive

cache-directive = token [ "=" ( token / quoted-string ) ]

unless it says otherwise, a cache directive below has NO argument (and isn't allowed one) 🙅‍♀️

5.2.1. Request Cache-Control Directives 💌

5.2.1.1. max-age ⏳

Argument syntax: delta-seconds (see Section 1.2.1)

the max-age request directive means the client is NOT up for accepting a response whose age is bigger than the number of seconds given 😤 unless max-stale is also in the mix, the client won't accept a stale response either 🙅‍♀️

this one uses the token form of the argument, so it's 'max-age=5' and absolutely not 'max-age="5"' 💅 a sender SHOULD NOT generate the quoted-string form 🫠

5.2.1.2. max-stale 🍰

Argument syntax: delta-seconds (see Section 1.2.1)

the max-stale request directive says the client is cool with a response that's gone past its freshness lifetime ✨ if it has a value, the client will take a stale response as long as it's only over by that many seconds or less 🕐 if there's no value at all, the client will accept a stale response of ANY age 🤷‍♀️💀

same as before, use the token form: 'max-stale=10' not 'max-stale="10"' 🎀 a sender SHOULD NOT generate the quoted-string form 🙈

5.2.1.3. min-fresh 🌷

Argument syntax: delta-seconds (see Section 1.2.1)

the min-fresh request directive means the client will accept a response whose freshness lifetime is at least its current age plus the number of seconds given 🧠 basically the client wants something that'll still be fresh for at least that long 🕰️💜

token form again, 'min-fresh=20' not 'min-fresh="20"' 💅 a sender SHOULD NOT generate the quoted-string form 🫶

5.2.1.4. no-cache 🚫

the no-cache request directive means a cache MUST NOT use a stored response to satisfy the request unless it has been successfully validated on the origin server 🙅‍♀️ no shortcuts, bestie 😤

5.2.1.5. no-store 🔐

the no-store request directive means a cache MUST NOT store any part of this request or any response to it 🤐 it covers both private and shared caches 🍓

"MUST NOT store" here has a specific meaning: the cache MUST NOT intentionally put the information in non-volatile storage, and it MUST make a best-effort attempt to clear the info out of volatile storage as quickly as it can after forwarding it 🧹✨

this directive is NOT a reliable or sufficient way to protect privacy 🙈 malicious or compromised caches might ignore it, and networks can be eavesdropped on 👀 so don't bet your whole secret on it 💀

also, if a request with this directive gets satisfied from a cache, the no-store request directive doesn't reach back and apply to the response that's already stored 🤓

5.2.1.6. no-transform 🧃

the no-transform request directive says an intermediary (whether or not it has a cache) MUST NOT transform the payload, as defined in Section 5.7.2 of [RFC7230] 🙅‍♀️ hands off the payload, please 🫶

5.2.1.7. only-if-cached 🏃‍♀️

the only-if-cached request directive means the client only wants a stored response, period 📦 when a cache gets this, it SHOULD either reply with a stored response that still fits the other constraints of the request, or send back a 504 (Gateway Timeout) status code ⏰ if a bunch of caches are run as one unified system with solid internal connectivity, a member cache MAY forward this request within that group 🤝

5.2.2. Response Cache-Control Directives 🎁

5.2.2.1. must-revalidate 🧾

the must-revalidate response directive means once the response has gone stale, a cache MUST NOT use it for later requests unless it has been successfully validated on the origin server 🛑

this directive is really needed for certain protocol features to work reliably 🔧 in every situation a cache MUST obey must-revalidate 🫡 and if a cache can't reach the origin server for any reason, it MUST generate a 504 (Gateway Timeout) response 🌩️

servers ought to use must-revalidate if and only if failing to validate the representation could lead to incorrect behaviour, like a financial transaction that quietly never gets executed 💸😱

5.2.2.2. no-cache 🙅‍♀️

Argument syntax: #field-name

the no-cache response directive means the response MUST NOT be used for a later request unless it's been successfully validated on the origin server 🔒 this lets an origin stop a cache from serving it without checking in, even caches that were set up to send stale responses 😤

if the no-cache response directive lists one or more field-names, then a cache MAY use the response for a later request, as long as the other caching rules are happy too 🌈 BUT any header fields in the response with those field-names MUST NOT be sent in response to a later request unless they're revalidated with the origin server first 🫶 this way the origin can stop certain headers from being reused while the rest of the response still gets cached 🍰

the field-names aren't limited to the headers this spec defines 💖 and field names are case-insensitive 🔤

this directive uses the quoted-string form of the argument 🎀 a sender SHOULD NOT generate the token form, even if quotes look unnecessary for a single-item list 🙈

Note: even though it's been backported to lots of implementations, some HTTP/1.0 caches won't recognise or obey this directive 😬 also, caches often treat no-cache with field-names like a plain unqualified no-cache, so the special handling for the qualified version isn't widely implemented 💀

5.2.2.3. no-store 🔐

the no-store response directive means a cache MUST NOT store any part of the immediate request or response 🤐 it covers private and shared caches alike 🍓

just like before, "MUST NOT store" means the cache MUST NOT intentionally keep the info in non-volatile storage, and MUST make a best-effort attempt to remove it from volatile storage as promptly as possible after forwarding 🧹

this directive is NOT a reliable or sufficient privacy mechanism 🙈 malicious or compromised caches might not notice or obey it, and communication networks might be open to eavesdropping 👀

5.2.2.4. no-transform 🧃

the no-transform response directive says an intermediary (regardless of whether it implements a cache) MUST NOT transform the payload, as defined in Section 5.7.2 of [RFC7230] 🙅‍♀️ same energy as the request version, no touching the payload 🫶

5.2.2.5. public 🌞

the public response directive means any cache MAY store the response, even if it'd normally be non-cacheable or only cacheable in a private cache 🌈 (see Section 3.2 for extra details on using public with a request that includes Authorization, and Section 3 for how public affects responses that wouldn't normally be stored because their status codes aren't cacheable by default; see Section 4.2.2 too 📚✨)

5.2.2.6. private 🫣

Argument syntax: #field-name

the private response directive means the response is meant for one single user and MUST NOT be stored by a shared cache 🙅‍♀️ a private cache MAY store it and reuse it for later requests, even if it'd normally be non-cacheable 💜

if private lists one or more field-names, the rule only applies to the field-values of those listed response headers 🎯 so a shared cache MUST NOT store the specified field-name(s), but it MAY store the rest of the response message 🍰

the field-names aren't limited to this spec's headers either 💖 and they're case-insensitive 🔤

this directive uses the quoted-string form of the argument 🎀 a sender SHOULD NOT generate the token form, even if quotes seem unnecessary for a single-item list 🙈

Note: this use of the word "private" only controls where the response can be stored; it can NOT keep the message content private 🙃 also, caches often treat private with field-names as a plain unqualified private, so the special handling for the qualified form isn't widely implemented 😭

5.2.2.7. proxy-revalidate 🤝

the proxy-revalidate response directive means the same thing as must-revalidate, except it does NOT apply to private caches 🛡️

5.2.2.8. max-age ⏳

Argument syntax: delta-seconds (see Section 1.2.1)

the max-age response directive says the response should be considered stale once its age goes past the number of seconds given 🕰️💅

this uses the token form of the argument: 'max-age=5' not 'max-age="5"' 🎀 a sender SHOULD NOT generate the quoted-string form 🫠

this part's a wrap, and we're really getting into the thick of it now 💖

5.2.2.9. s-maxage 💖

okay so the argument syntax is:

delta-seconds (see Section 1.2.1)

the s-maxage response directive is giving main character energy in shared caches 👑. The max age set by this directive overrides the max age from either the max-age directive or the Expires header field. It also brings the semantics of proxy-revalidate along with it 🫶.

this one uses the token form of the argument syntax, so it's s-maxage=10 and not s-maxage="10". A sender SHOULD NOT generate the quoted-string form 🙈.

5.2.3. Cache Control Extensions ✨

the Cache-Control header field can be extended with one or more cache-extension tokens, and each one can have an optional value 🧚. A cache MUST ignore unrecognized cache directives 💀.

Informational extensions are the ones that don't need a change in cache behavior, so they can be added without changing the semantics of other directives 🌸.

Behavioral extensions work as modifiers to the existing directives 🦋. Both the new directive and the old one get sent, so apps that don't understand the new one just fall back to the old behavior, and apps that do understand it know it's changing the requirements of the old one. That's how you can extend cache-control directives without breaking deployed caches, and honestly it's so smart 😭.

for example, imagine a hypothetical new response directive called "community" that modifies the private directive. In addition to private caches, any cache that's shared only by members of the named community is allowed to store the response. An origin server that wants the UCI community to use an otherwise private response in their shared cache(s) could do it by including:

Cache-Control: private, community="UCI"

a cache that recognizes this community cache-extension can broaden its behavior to match 🎀. A cache that doesn't recognize it will just ignore it and follow the private directive 💅.

5.3. Expires 🌈

the "Expires" header field gives the date/time after which the response is considered stale. For more on the freshness model, check out Section 4.2 🍓.

the presence of an Expires field does NOT imply that the original resource will change or cease to exist at, before, or after that time. (ok the real sentence has no caps, I'm just being dramatic 🙈) It's just a timestamp, nothing more.

the Expires value is an HTTP-date timestamp, as defined in Section 7.1.1.1 of [RFC7231] 📚.

Expires = HTTP-date

for example:

Expires: Thu, 01 Dec 1994 16:00:00 GMT
A cache recipient MUST interpret invalid date formats, especially the value "0", as representing a time in the past (i.e., "already expired"). Bestie, this one is serious 😭.

if a response includes a Cache-Control field with the max-age directive (Section 5.2.2.8), a recipient MUST ignore the Expires field 💅. Likewise, if a response includes the s-maxage directive (Section 5.2.2.9), a shared cache recipient MUST ignore the Expires field 🫶. In both of these cases, the value in Expires is only for recipients that haven't implemented the Cache-Control field yet 🦋.

an origin server without a clock MUST NOT generate an Expires field, unless its value represents a fixed time in the past (always expired) or its value has been associated with the resource by a system or user with a reliable clock ⏰.

historically, HTTP required the Expires field-value to be no more than a year in the future. Longer freshness lifetimes aren't prohibited anymore, but extremely large values have caused problems, like clock overflows from using 32-bit integers for time values 💀. Plus, many caches will evict a response way sooner than that 🌸.

5.4. Pragma 🌷

the "Pragma" header field keeps things backwards compatible with HTTP/1.0 caches. That way clients can send a "no-cache" request that those older caches understand, since Cache-Control wasn't defined until HTTP/1.1 👵. When the Cache-Control header field is also present and understood in a request, Pragma gets ignored 🙈.

in HTTP/1.0, Pragma was an extensible field for implementation-specified directives for recipients. This specification deprecates those extensions to improve interoperability 💜.

Pragma           = 1#pragma-directive
pragma-directive = "no-cache" / extension-pragma
extension-pragma = token [ "=" ( token / quoted-string ) ]

when the Cache-Control header field is NOT present in a request, caches MUST consider the no-cache request pragma-directive as having the same effect as if "Cache-Control: no-cache" were present (see Section 5.2.1) 🧚.

when a client sends a no-cache request, it ought to include both the pragma and cache-control directives. The exception is when Cache-Control: no-cache is purposefully left out to target other Cache-Control response directives at HTTP/1.1 caches ✨. For example:

GET / HTTP/1.1
Host: www.example.com
Cache-Control: max-age=30
Pragma: no-cache

this will constrain HTTP/1.1 caches to serve a response no older than 30 seconds, while blocking implementations that don't understand Cache-Control from serving a cached response 🎀.

Note: Because the meaning of "Pragma: no-cache" in responses is not specified, it does not provide a reliable replacement for "Cache-Control: no-cache" in them. 💅

5.5. Warning ⚠️

the "Warning" header field carries extra info about the status or transformation of a message that might not be reflected in the status code 🔥. It's usually used to warn about possible incorrectness caused by caching operations or transformations applied to the message payload 🍓.

warnings can be used for other purposes too, both cache-related and not. Using a warning instead of an error status code is what separates these responses from true failures 🦋.

warning header fields can generally be applied to any message, but some warn-codes are specific to caches and can only go on response messages 💖.

Warning       = 1#warning-value

warning-value = warn-code SP warn-agent SP warn-text
                                      [ SP warn-date ]

warn-code  = 3DIGIT
warn-agent = ( uri-host [ ":" port ] ) / pseudonym
                ; the name or pseudonym of the server adding
                ; the Warning header field, for use in debugging
                ; a single "-" is recommended when agent unknown
warn-text  = quoted-string
warn-date  = DQUOTE HTTP-date DQUOTE

multiple warnings can show up in a response, whether they come from the origin server or a cache. That includes multiple warnings with the same warn-code number that only differ in warn-text 🌈.

a user agent that receives one or more Warning header fields SHOULD inform the user of as many of them as possible, in the order they appear in the response 👑. Senders that generate multiple Warning header fields are encouraged to order them with this user agent behavior in mind 🫶. A sender that generates new Warning header fields MUST append them after any existing Warning header fields 💅.

warn-codes are assigned three digit numbers. The first digit tells you whether the Warning has to be deleted from a stored response after validation 🧚:

  • 1xx warn-codes describe the freshness or validation status of the response. They MUST be deleted by a cache after validation. They can only be generated by a cache when it's validating a cached entry, and they MUST NOT be generated in any other situation 🙈.
  • 2xx warn-codes describe some aspect of the representation that validation doesn't fix (for example, a lossy compression of the representation). They MUST NOT be deleted by a cache after validation, unless a full response is sent, in which case they MUST be deleted 🌸.

if a sender generates one or more 1xx warn-codes in a message to be sent to a recipient known to implement only HTTP/1.0, the sender MUST include a warn-date in each corresponding warning-value that matches the Date header field in the message. For example:

HTTP/1.1 200 OK
Date: Sat, 25 Aug 2012 23:34:45 GMT
Warning: 112 - "network down" "Sat, 25 Aug 2012 23:34:45 GMT"

warnings come with warn-text that describes the error, which is handy for logging 📝. It's advisory only, and its content does not affect how the warn-code is interpreted 🌷.

if a recipient that uses, evaluates, or displays Warning header fields gets a warn-date that's different from the Date value in the same message, the recipient MUST exclude the warning-value containing that warn-date before storing, forwarding, or using the message 🚫. This lets recipients drop warning-values that were wrongly kept after a cache validation 💜. If all of the warning-values get excluded, the recipient MUST exclude the Warning header field as well 💀.

the following warn-codes are defined by this specification. Each one has a recommended warn-text in English and a description of what it means. To define additional warn-codes, see Section 7.2.1 🎀.

5.5.1. Warning: 110 - "Response is Stale" 🥀

a cache SHOULD generate this whenever the response it sends is stale 😭.

5.5.2. Warning: 111 - "Revalidation Failed" 🙈

a cache SHOULD generate this when it sends a stale response because an attempt to validate the response failed, due to being unable to reach the server 📡.

5.5.3. Warning: 112 - "Disconnected Operation" 🔌

a cache SHOULD generate this if it's intentionally disconnected from the rest of the network for a period of time 🌙.

5.5.4. Warning: 113 - "Heuristic Expiration" 🧠

a cache SHOULD generate this if it heuristically chose a freshness lifetime greater than 24 hours and the response's age is greater than 24 hours ⏳.

5.5.5. Warning: 199 - "Miscellaneous Warning" 📣

the warning text can include arbitrary info for a human user to see or for logging. A system that receives this warning MUST NOT take any automated action, besides presenting the warning to the user 🙅‍♀️.

5.5.6. Warning: 214 - "Transformation Applied" 🪄

this Warning code MUST be added by a proxy if it applies any transformation to the representation, like changing the content-coding, media-type, or modifying the representation data. The exception is if this Warning code already appears in the response 🫧.

5.5.7. Warning: 299 - "Miscellaneous Persistent Warning" 🌟

the warning text can include arbitrary info for a human user to see or for logging. A system that receives this warning MUST NOT take any automated action 🛑.

6. History Lists 📜

user agents often have history mechanisms, like "Back" buttons and history lists, that can redisplay a representation retrieved earlier in a session 🔙.

the freshness model (Section 4.2) doesn't necessarily apply to history mechanisms. That means a history mechanism can display a previous representation even if it has expired 🕰️.

this doesn't stop the history mechanism from telling the user that a view might be stale, or from honoring cache directives (e.g., Cache-Control: no-store) 🫶.

7. IANA Considerations 🗂️

7.1. Cache Directive Registry 💅

the "Hypertext Transfer Protocol (HTTP) Cache Directive Registry" defines the namespace for the cache directives. It's been created and is now maintained at http://www.iana.org/assignments/http-cache-directives ✨.

7.1.1. Procedure 📝

A registration MUST include the following fields:

  • Cache Directive Name
  • Pointer to specification text

Values to be added to this namespace require IETF Review (see [RFC5226], Section 4.1).

7.1.2. Considerations for New Cache Control Directives 💭

New extension directives ought to consider defining:

  • What it means for a directive to be specified multiple times,
  • When the directive does not take an argument, what it means when an argument is present,
  • When the directive requires an argument, what it means when it is missing,
  • Whether the directive is specific to requests, responses, or able to be used in either.

See also Section 5.2.3. 🌸

7.1.3. Registrations 🎀

The registry has been populated with the registrations below:

+------------------------+----------------------------------+
| Cache Directive        | Reference                        |
+------------------------+----------------------------------+
| max-age                | Section 5.2.1.1, Section 5.2.2.8 |
| max-stale              | Section 5.2.1.2                  |
| min-fresh              | Section 5.2.1.3                  |
| must-revalidate        | Section 5.2.2.1                  |
| no-cache               | Section 5.2.1.4, Section 5.2.2.2 |
| no-store               | Section 5.2.1.5, Section 5.2.2.3 |
| no-transform           | Section 5.2.1.6, Section 5.2.2.4 |
| only-if-cached         | Section 5.2.1.7                  |
| private                | Section 5.2.2.6                  |
| proxy-revalidate       | Section 5.2.2.7                  |
| public                 | Section 5.2.2.5                  |
| s-maxage               | Section 5.2.2.9                  |
| stale-if-error         | [RFC5861], Section 4             |
| stale-while-revalidate | [RFC5861], Section 3             |
+------------------------+----------------------------------+

7.2. Warn Code Registry 🚨

The "Hypertext Transfer Protocol (HTTP) Warn Codes" registry defines the namespace for warn codes. It has been created and is now maintained at <http://www.iana.org/assignments/http-warn-codes>.

7.2.1. Procedure 📝

A registration MUST include the following fields:

  • Warn Code (3 digits)
  • Short Description
  • Pointer to specification text

Values to be added to this namespace require IETF Review (see [RFC5226], Section 4.1).

7.2.2. Registrations 🎀

The registry has been populated with the registrations below:

+-----------+----------------------------------+---------------+
| Warn Code | Short Description                | Reference     |
+-----------+----------------------------------+---------------+
| 110       | Response is Stale                | Section 5.5.1 |
| 111       | Revalidation Failed              | Section 5.5.2 |
| 112       | Disconnected Operation           | Section 5.5.3 |
| 113       | Heuristic Expiration             | Section 5.5.4 |
| 199       | Miscellaneous Warning            | Section 5.5.5 |
| 214       | Transformation Applied           | Section 5.5.6 |
| 299       | Miscellaneous Persistent Warning | Section 5.5.7 |
+-----------+----------------------------------+---------------+

7.3. Header Field Registration 🦋

HTTP header fields are registered within the "Message Headers" registry maintained at <http://www.iana.org/assignments/message-headers/>.

This document defines the following HTTP header fields, so the "Permanent Message Header Field Names" registry has been updated accordingly (see [BCP90]).

+-------------------+----------+----------+-------------+
| Header Field Name | Protocol | Status   | Reference   |
+-------------------+----------+----------+-------------+
| Age               | http     | standard | Section 5.1 |
| Cache-Control     | http     | standard | Section 5.2 |
| Expires           | http     | standard | Section 5.3 |
| Pragma            | http     | standard | Section 5.4 |
| Warning           | http     | standard | Section 5.5 |
+-------------------+----------+----------+-------------+

The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".

8. Security Considerations 🔐

This section is meant to inform developers, information providers, and users of known security concerns specific to HTTP caching. More general security considerations are addressed in HTTP messaging [RFC7230] and semantics [RFC7231].

Caches expose additional potential vulnerabilities, since the contents of the cache represent an attractive target for malicious exploitation. Because cache contents persist after an HTTP request is complete, an attack on the cache can reveal information long after a user believes that the information has been removed from the network. Therefore, cache contents need to be protected as sensitive information. 😱

In particular, various attacks might be amplified by being stored in a shared cache. Such "cache poisoning" attacks use the cache to distribute a malicious payload to many clients, and are especially effective when an attacker can use implementation flaws, elevated privileges, or other techniques to insert such a response into a cache. One common attack vector for cache poisoning is to exploit differences in message parsing on proxies and in user agents; see Section 3.3.3 of [RFC7230] for the relevant requirements. 💀

Likewise, implementation flaws (as well as misunderstanding of cache operation) might lead to caching of sensitive information (e.g., authentication credentials) that is thought to be private, exposing it to unauthorized parties.

Furthermore, the very use of a cache can bring about privacy concerns. For example, if two users share a cache, and the first one browses to a site, the second may be able to detect that the other has been to that site, because the resources from it load more quickly, thanks to the cache. 🙈

Note that the Set-Cookie response header field [RFC6265] does not inhibit caching; a cacheable response with a Set-Cookie header field can be (and often is) used to satisfy subsequent requests to caches. Servers who wish to control caching of these responses are encouraged to emit appropriate Cache-Control response header fields. 🍓

9. Acknowledgments 🫶

See Section 10 of [RFC7230].

10. References 📚

10.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014.

[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.

[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, June 2014.

[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, June 2014.

[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014.

10.2. Informative References

[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

[RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale Content", RFC 5861, April 2010.

[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.

[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011.

Appendix A. Changes from RFC 2616 🧾

The specification has been substantially rewritten for clarity.

The conditions under which an authenticated response can be cached have been clarified. (Section 3.2)

New status codes can now define that caches are allowed to use heuristic freshness with them. Caches are now allowed to calculate heuristic freshness for URIs with query components. (Section 4.2.2)

The algorithm for calculating age is now less conservative. Caches are now required to handle dates with time zones as if they're invalid, because it's not possible to accurately guess. (Section 4.2.3)

The Content-Location response header field is no longer used to determine the appropriate response to use when validating. (Section 4.3)

The algorithm for selecting a cached negotiated response to use has been clarified in several ways. In particular, it now explicitly allows header-specific canonicalization when processing selecting header fields. (Section 4.1)

Requirements regarding denial-of-service attack avoidance when performing invalidation have been clarified. (Section 4.4)

Cache invalidation only occurs when a successful response is received. (Section 4.4)

Cache directives are explicitly defined to be case-insensitive. Handling of multiple instances of cache directives when only one is expected is now defined. (Section 5.2)

The "no-store" request directive doesn't apply to responses; i.e., a cache can satisfy a request with no-store on it and does not invalidate it. (Section 5.2.1.5)

The qualified forms of the private and no-cache cache directives are noted to not be widely implemented; for example, "private=foo" is interpreted by many caches as simply "private". Additionally, the meaning of the qualified form of no-cache has been clarified. (Section 5.2.2)

The "no-cache" response directive's meaning has been clarified. (Section 5.2.2.2)

The one-year limit on Expires header field values has been removed; instead, the reasoning for using a sensible value is given. (Section 5.3)

The Pragma header field is now only defined for backwards compatibility; future pragmas are deprecated. (Section 5.4)

Some requirements regarding production and processing of the Warning header fields have been relaxed, as it is not widely implemented. Furthermore, the Warning header field no longer uses RFC 2047 encoding, nor does it allow multiple languages, as these aspects were not implemented. (Section 5.5)

This specification introduces the Cache Directive and Warn Code Registries, and defines considerations for new cache directives. (Section 7.1 and Section 7.2)

Appendix B. Imported ABNF 🎀

okay so bestie, this is the part where the doc says "we're borrowing some core rules from other specs, no need to retype them" 💅 The core rules come in by reference, as defined in Appendix B.1 of [RFC5234]. Here they are:

  • ALPHA (letters) ✨
  • CR (carriage return) 🌸
  • CRLF (CR LF) 🦋
  • CTL (controls) 💜
  • DIGIT (decimal 0-9) 🔢
  • DQUOTE (double quote) 🎀
  • HEXDIG (hexadecimal 0-9/A-F/a-f) 🍓
  • LF (line feed) 🌈
  • OCTET (any 8-bit sequence of data) 👑
  • SP (space) 🫶
  • VCHAR (any visible US-ASCII character) ⭐

the next bit is giving "these rules live in [RFC7230] and we're just pointing at them" energy 🧚

OWS           = <OWS, see [RFC7230], Section 3.2.3>
field-name    = <field-name, see [RFC7230], Section 3.2>
quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
token         = <token, see [RFC7230], Section 3.2.6>

port          = <port, see [RFC7230], Section 2.7>
pseudonym     = <pseudonym, see [RFC7230], Section 5.7.1>
uri-host      = <uri-host, see [RFC7230], Section 2.7>

and then there's the last one, which is defined somewhere else entirely, in [RFC7231] 🙈

HTTP-date     = <HTTP-date, see [RFC7231], Section 7.1.1.1>

Appendix C. Collected ABNF 💜

okay this is the grand finale of grammars 😭 all the ABNF in one place, and as the doc says, list rules get expanded as per Section 1.2 of [RFC7230]. Honestly the whole thing is a lot, but it's the one-stop shop for anyone building a parser, so it's giving main character energy 👑

Age = delta-seconds

Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS
 cache-directive ] )

Expires = HTTP-date

HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>

OWS = <OWS, see [RFC7230], Section 3.2.3>

Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS
 pragma-directive ] )

Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ]
 )

cache-directive = token [ "=" ( token / quoted-string ) ]

delta-seconds = 1*DIGIT

extension-pragma = token [ "=" ( token / quoted-string ) ]

field-name = <field-name, see [RFC7230], Section 3.2>

port = <port, see [RFC7230], Section 2.7>
pragma-directive = "no-cache" / extension-pragma
pseudonym = <pseudonym, see [RFC7230], Section 5.7.1>

quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>

token = <token, see [RFC7230], Section 3.2.6>

uri-host = <uri-host, see [RFC7230], Section 2.7>

warn-agent = ( uri-host [ ":" port ] ) / pseudonym
warn-code = 3DIGIT
warn-date = DQUOTE HTTP-date DQUOTE
warn-text = quoted-string
warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date
 ]

Index 🦋

the index is basically a treasure map 🗺️ every term, every directive, every warn-text, and the page numbers they live on. the pages are from the original, so they're as accurate as the doc itself 💖

1
   110 (warn-code)  31
   111 (warn-code)  31
   112 (warn-code)  31
   113 (warn-code)  31
   199 (warn-code)  32

2
   214 (warn-code)  32
   299 (warn-code)  32

A
   age  11
   Age header field  21

C
   cache  4
   cache entry  5
   cache key  5-6
   Cache-Control header field  21

D
   Disconnected Operation (warn-text)  31

E
   Expires header field  28
   explicit expiration time  11

F
   fresh  11
   freshness lifetime  11

G
   Grammar
      Age  21
      Cache-Control  22
      cache-directive  22
      delta-seconds  5
      Expires  28
      extension-pragma  29
      Pragma  29
      pragma-directive  29
      warn-agent  29
      warn-code  29
      warn-date  29
      warn-text  29
      Warning  29
      warning-value  29

H
   Heuristic Expiration (warn-text)  31
   heuristic expiration time  11
M
   max-age (cache directive)  22, 26
   max-stale (cache directive)  22
   min-fresh (cache directive)  22
   Miscellaneous Persistent Warning (warn-text)  32
   Miscellaneous Warning (warn-text)  32
   must-revalidate (cache directive)  24

N
   no-cache (cache directive)  23, 25
   no-store (cache directive)  23, 24
   no-transform (cache directive)  23, 25

O
   only-if-cached (cache directive)  23

P
   Pragma header field  29
   private (cache directive)  25
   private cache  4
   proxy-revalidate (cache directive)  26
   public (cache directive)  25

R
   Response is Stale (warn-text)  30
   Revalidation Failed (warn-text)  31

S
   s-maxage (cache directive)  27
   shared cache  4
   stale  11
   strong validator  18

T
   Transformation Applied (warn-text)  32

V
   validator  16

W
   Warning header field  29

Authors' Addresses 🫶

and finally, the people who wrote this whole thing 🥹 here are the editors and their contact details, copied exactly as they appear in the original:

Roy T. Fielding (editor)
Adobe Systems Incorporated
345 Park Ave
San Jose, CA  95110
USA

EMail: fielding@gbiv.com
URI:   http://roy.gbiv.com/


Mark Nottingham (editor)
Akamai

EMail: mnot@mnot.net
URI:   http://www.mnot.net/


Julian F. Reschke (editor)
greenbytes GmbH
Hafenweg 16
Muenster, NW  48155
Germany

EMail: julian.reschke@greenbytes.de
URI:   http://greenbytes.de/tech/webdav/

that's the whole spec, bestie!! 🌈✨ thank u for being the most patient study buddy 💖

📦 where this page comes from