 Okay. Thank you for coming. For the next 15 minutes, we will talk about the new features and the past and the present also of the HTTP cache. First, I will introduce myself. I'm a French baguette, so I have a bad accent in English. I'm the creator of the Swan HTTP cache. That's an HTTP cache written in Go. And I'm also the maintainer of the KD cache handler. And I'm an active open-source contributor. You can find me on GitHub searching Darkwick and Darkwick Dev on Twitter. So you can ask questions during the conference, but this talk is really, really small. So you can ask after outside. I want to say the tech is political. So if you want to fight some governments, directives, or something else, you can do that at your point. And also, I manage some students. So if you want to some coaching or anything else in Go, React or PHP, just send me an email and we'll see that. So go back in the past. There were too many providers that bring us some internet features. And we had the HTTP 1.0. But this version was the first stable version of the HTTP protocol. But there was a lack of description and a lack of customization. Some providers like Google or Akamai tried to implement on their own ways new features. But each provider implemented it on their own ways. So the behavior could be different from Google to Akamai. And support that, support all providers, was impossible. In June 1999, Matrix was available at the cinema. And they released the RFC 2616, also called HTTP 1.1. So an RFC is a buy-it blog, like 60 pages. And it's a fully technical buy-it blog. And this RFC introduced some grammar about the HTTP request response, what is a request body, how to define it more specifically and precisely in this description. It introduced some HTTP headers that we are using today, like the content encoding or content type, the range, and many other headers that are still in the HTTP protocol today. But in this RFC, we have the first part of the stable caching in HTTP. And it starts with the following sentence. Caching would be useless if it didn't significantly improve performance. So in the past, it was true. The cache was only for performance. But today, we have some ecological goals. And if your cache consumes 10 or 20 times more than your upstream, maybe you don't need your caching system. And as it was the first release of the HTTP caching system, there was some bad sentences, like this one. If a stored response is not fresh enough, so it couldn't be served to your client. The cache may still return the response to the client. So it's not good because if your client don't want cached response, you have to respect his choice. And you can see there is a warning header here. So you can still use it. Nobody uses it today, but it exists. It introduced some cache control directive. So there were none, no cache and no store. No cache don't say don't serve the cache. But if you find a request or a response with the no cache, you have to revalidate with the server. A revalidation is like a normal request, but on your upstream, if the content didn't change, you have to return a not modified status code in your response. No store will say, okay, the return response mustn't be stored in your cache. The max age directive will say, I accept the response and consider it as a fresh if it has been stored for x seconds. So if you say max age equal five, you can't serve a cached response that has been cached for more than five seconds. And no transform, ensure that your proxy will not modify your request or your response. It can't add any iterals and cannot edit the contents. The directive only for request, you have the max tail to say, okay, you can serve me a stale response for x seconds. It's the same as max age, but for the stale format. The mean fresh, it's not used in production because it says, okay, if your response is stored for since x seconds, you can serve me and contact the upstream otherwise. And only if cached say, okay, if you have a cached response, you can send me that. In the response context, we have the public that say your response can be stored in any cache system, private and shared cache. Private should be stored only on your browser cache because it's a private cache or your proxy should implement the private cache system. The must revalidate will try to revalidate each time you serve this response to the server to check if it's fresh enough and if the content shoots to the expectation. The proxy will revalidate will trigger revalidation only on your proxy and not on your browser, for example. And the s max age is like the max age, but for shared cache. We have some extensions to extend these directives. And it's like a key value to implement some custom logic in your cache systems. So here with community key, we define the value UCI and you can say, okay, if the value is UCI for this key, I will store for 10 seconds and five seconds otherwise. In August 2001, Google image was released and we discovered the ESI language. The ESI language comes with the ESI tags. Who already wants some HTML in his job or nobody? Okay. I won't explain what is HTML. So here you return a web article and you have the full page that would be cached in your varnish server, for example. But you have a dynamic either with the user.php call. Your client will say, okay, send me article.html. It will request on the web server the whole article. It will parse the HTML content and detect an ESI tag and make another request to user.php. Get the response and replace the ESI block in your full page by the user.php response. Here is an example with the ESI include. We have some different kind of tags. The include will define the source and the alt. If the source fails, it will try the alt and on a wall, you can say fail and it will stop the render of the page. And if it's on the continue, it will just omit that and replace by a blank character. We have some try-catch blocks. And we can interpolate some variables. Here I will get from the cookies, the type and logoname and it will replace from this value to give me this HTML tag at the end. So here is an example for what could be your page with some different ESI tags and customize the TTL for each ESI tag blocks. In 2014, the RFC 7234 defines the wall caching, providing us a new HTTP header called age. That can be negative. And it defines invalidation because the get request can be cached. But if you send a put delete or a post request on the same resource, you have to invalidate now the get resource in cache. The stale validate is a new directive to say, okay, you can send me stale content, but you have to revalidate asynchronously with your upstream server. HTTP 2, better performance is that good. You have to enable that on your server. Some diagrams to illustrate how it works and why it is faster thanks to the multiplexing. And everything is in the same pipe despite the HTTP one. In 2022, they released two new RFCs, the cache status and the targeted cache control. The RFC cache status defines some directive to say, okay, my cache status, it's some cache response or forward because of that, of why it has been forwarded. Here, the first will hit and the TTL will say it will be fresh for three seconds. The second one is an URI miss. So it didn't find the URI in the cache and the upstream returned a not modified status code. And the third is also a new IRI miss because I have a detailed directive to say my storage was unreachable. As a targeted cache control, your upstream will return some new cache control prefixed by a name. So we have the CDN, varnish and KD and all your services will interpret and focus on this HTTP header to manage that cache. So KD will handle only KD cache control and it will store for one hour, varnish for five minutes and the CDN for two minutes. And it will fall back on the cache control if none other match. And the client will store for no store because it will revalidate each time he's doing its request. And what are the images? What about the future? Probably in June because all the IRFC are released in June. The surrogate keys will allow you to group your cache keys and invalidate them by a global key. Global key name. First group, second group and third group. No images too. There was so much implementation with Cloudflare, Akamai, etc. And I think I don't have the images. There was a queue code to a new IRFC that is currently written but you won't have it. And the resources, obviously no images. You have the IRFC. And that's beautiful with that. But we have the GIF at the end.