Quoi de neuf dans le monde du cache HTTP

What's new in the HTTP cache world

What's new in the HTTP cache world

Disclaimer

✊ Tech is political

💬 Ask during the conference

Join onestlatech in 🇫🇷

What is the HTTP cache?

What is the HTTP cache

Bonjour, j'aimerai savoir de quoi parle Harry Potter

Très bien, laissez-moi quelques secondes

A concrete example

A concrete example

A concrete example

C'est un roman fantastique qui traite de la magie

A concrete example

A concrete example

A concrete example

Bonjour, j'aimerai savoir de quoi parle Harry Potter

C'est un roman fantastique qui traite de la magie

A concrete example

Sylvain Combraque

Go/ReactJS architect freelance

Polyglot dev

Cache-handler maintainer 

Open-source contributor

@Darkweak

@Darkweak_dev

Thanks to Shanti

Head of happiness in my house

In the IT world

The chaos between the providers

HTTP/1.0

📉 low description

📉 low customization

😮‍💨 lot of own implementations

June 1999

RFC-2616

HTTP/1.1

The WWW beginnings

📚 Grammar

🕵️‍♂️ Resource identifier

🔗 URI

🔤 Content-Encoding

RFC-2616

13.x: Caching in HTTP

Caching would be useless if it did not significantly improve performance

RFC-2616

13.x: Caching in HTTP

If a stored response is not "fresh enough" [...] the cache MAY still return the response with the appropriate Warning header

RFC-2616

Cache-Control commons

🙅‍♂️ no-cache

✋ no-store

⏱️ max-age

🫡 no-transform

RFC-2616

Cache-Control HTTP request

⏱️ max-stale

🤷‍♂️ min-fresh

💁‍♂️ only-if-cached

RFC-2616

🔓 public

🔐 private

🤙 must-revalidate

🤙 proxy-revalidate

⏱️ s-maxage

Cache-Control HTTP response

RFC-2616

  • community="UCI"

  • only-if-my-case-match="that-should"

Cache-Control cache-extension

Let me introduce

Mark Nottingham

@mnot

Multiple RFC creator (38)

Fastly, Cloudflare, Akamai

Performances

Won't answer to your questions

When you think it's simple, RFC tells you it is not
1. Introduction

HTTP is typically used for distributed information systems, where performance can be improved by the use of response caches. This document defines aspects of HTTP/1.1 related to caching and reusing response messages. An HTTP cache is a local store of response messages and the subsystem that controls storage, retrieval, and deletion of messages in it. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests. Any client or server MAY employ a cache, though a cache cannot be used by a server that is acting as a tunnel. A shared cache is a cache that stores responses to be reused by more than one user; shared caches are usually (but not always) deployed as a part of an intermediary. A private cache, in contrast, is dedicated to a single user; often, they are deployed as a component of a user agent. The goal of caching in HTTP/1.1 is to significantly improve performance by reusing a prior response message to satisfy a current request. A stored response is considered "fresh", as defined in Section 4.2, if the response can be reused without "validation" (checking with the origin server to see if the cached response remains valid for this request). A fresh response can therefore reduce both latency and network overhead each time it is reused. When a cached response is not 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 considerations regarding error handling are defined in Section 2.5 of [RFC7230].

1.2. Syntax Notation

This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] with a list extension, defined in Section 7 of [RFC7230], that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates Fielding, et al. Standards Track [Page 4]

RFC-7234

Request for comments

August 2001

ESI Language

ESI tags

ESI tags

<esi:include 
  src="http://example.com/1.html" 
  alt="http://bak.example.com/2.html" 
  onerror="continue"
/>

ESI tags

<esi:try> 
  <esi:attempt>
    <esi:comment text="Include an ad"/> 
    <esi:include src="http://www.example.com/ad1.html"/> 
  </esi:attempt>
  <esi:except> 
    <esi:comment text="Just write some HTML instead"/> 
    <a href=www.akamai.com>www.example.com</a>
  </esi:except> 
</esi:try>

ESI tags

<esi:vars>
  <img 
    src="http://www.example.com/$(HTTP_COOKIE{type})/hello.gif"
    alt="$(HTTP_COOKIE{logo_name})"
  />
</esi:vars>

ESI tags

<img 
  src="http://www.example.com/human/hello.gif"
  alt="My human GIF"
/>

ESI tags

ESI tags

June 2014

RFC-7234

HTTP/1.1 Caching

RFC-7234

HTTP response header Age

Age: 10
Age: -5

RFC-7234

Invalidation

2000 - REST

RFC-7234

Cache-Control HTTP response

🤘 stale-while-revalidate

RFC-7234

👋 Pragma

2015

HTTP/2

🏎💨

HTTP/2

HTTP/2

HTTP/2

June 2022

RFC-9211 & RFC-9213

The Cache-Status & Target-Cache-Control
HTTP response Header fields

RFC-9211

Cache-Status directives

💥 hit

📩 fwd

ℹ️ fwd-status

⏱️ ttl

👌 stored

🙏 collapsed

🔑 key

🤓 detail

RFC-9211

Cache-Status directives

Cache-Status: Your-Cache-Server; hit; ttl=3; key=your-pattern
Cache-Status: Your-Cache-Server; fwd=uri-miss; fwd-status=304
Cache-Status: Your-Cache-Server; fwd=uri-miss; detail=STORAGE-UNREACHABLE

RFC-9213

Target-Cache-Control

CDN

Varnish

Caddy 

Upstream

RFC-9213

Target-Cache-Control

CDN

Varnish

Caddy 

Upstream

RFC-9213

Target-Cache-Control

CDN

Varnish

Caddy 

Upstream

Cache-Control: no-store
CDN-Cache-Control: public, max-age=120, s-maxage=120
Varnish-Cache-Control: public, max-age=360, s-maxage=360
Caddy-Cache-Control: public, max-age=3600, s-maxage=3600

RFC-9213

Target-Cache-Control

CDN

Varnish

Caddy 

Upstream

Cache-Control: no-store
CDN-Cache-Control: public, max-age=120, s-maxage=120
Varnish-Cache-Control: public, max-age=360, s-maxage=360
Caddy-Cache-Control: public, max-age=3600, s-maxage=3600

3600s

RFC-9213

Target-Cache-Control

CDN

Varnish

Caddy 

Upstream

Cache-Control: no-store
CDN-Cache-Control: public, max-age=120, s-maxage=120
Varnish-Cache-Control: public, max-age=360, s-maxage=360
Caddy-Cache-Control: public, max-age=3600, s-maxage=3600

360s

RFC-9213

Target-Cache-Control

CDN

Varnish

Caddy 

Upstream

Cache-Control: no-store
CDN-Cache-Control: public, max-age=120, s-maxage=120
Varnish-Cache-Control: public, max-age=360, s-maxage=360
Caddy-Cache-Control: public, max-age=3600, s-maxage=3600

120s

RFC-9213

Target-Cache-Control

Cache-Control: no-store
CDN-Cache-Control: public, max-age=120, s-maxage=120
Varnish-Cache-Control: public, max-age=360, s-maxage=360
Caddy-Cache-Control: public, max-age=3600, s-maxage=3600

Client

no-cache

October 2025

RFC-9875

The HTTP Cache Groups

RFC-9875

New HTTP response headers

Cache-Groups

Cache-Group-Invalidation

RFC-9875

HTTP/1.1 200 OK

Content-Type: application/javascript

Cache-Control: max-age=3600

Cache-Groups: "scripts", "another"

RFC-9875

HTTP/1.1 200 OK

Content-Type: application/javascript

Cache-Control: max-age=3600

Cache-Groups: "/books"

RFC-9875

HTTP/1.1 200 OK

Content-Type: application/javascript

Cache-Control: max-age=3600

Cache-Groups-Invalidation: "one", "two"

RFC-9875

HTTP/1.1 200 OK

Content-Type: application/javascript

Cache-Control: max-age=3600

Cache-Groups-Invalidation: "/books"

RFC-9875

/books

one

two

/books?page=1

/books/1

/books?page=2

/books?name=L

/books/1

/users/1

/template/1

/other-resource

/books/2

/users/2

/template/2

/other-resource

RFC-9875

/books

one

two

/books?page=1

/books/1

/books?page=2

/books?name=L

/books/1

/users/1

/template/1

/other-resource

/books/2

/users/2

/template/2

/other-resource

Cache-Groups-Invalidation: "/books"

What about the future...

draft-nottingham-http-invalidation​

The HTTP Cache Groups Invalidation API

So much implementation

HTTP invalidation API

{
    "type": "uri",
    "selectors": [
      "https://example.com/foo/bar",
      "https://example.com/foo/bar/baz"
    ]
    "purge": false
}
{
    "type": "group",
    "selectors": [
      "https://example.com:443",
      "https://www.example.com:443"
    ],
    "groups": [
      "scripts"
    ]
}

POST /to/your/invalidation-api

Probably never go live

HTTP invalidation API

Resources

Resources

https://github.com/http-tests/cache-tests

https://cache-tests.fyi

Resources

https://www.rfc-editor.org

github.com/darkweak/souin

Leave a ⭐️ on Github

Lazy to manage an HTTP cache?

Thank you for your attention

Give your feedbacks👉