In-person Event - Kubernetes Community Days Provence 2026 🇫🇷Plongez au cœur de l’innovation Cloud Native Rejoignez-nous pour une journée dédiée au technologie AI et CloudNative .

This post summarizes our netkit paper from the eBPF’26 workshop at ACM SOSP. The netkit paper proposes an eBPF-based datapath to specialize the Linux networking stack and eliminate redundant backlog q...

[0.1.4] - 2026-09-14 Changed Bump AsBuiltReport.Chart to version 0.3.4 to include latest charting features and improvements Bump AsBuiltReport.Diagram to version 1.0.10 to include latest diagrammi...

Serie of sketchnotes about Kubernetes. Explaining in a visual way Kubernetes principles.

Root election, port roles, proposals and agreements, topology changes: explore RSTP through simulations powered by MSTPD compiled to WebAssembly.

Il y a des histoires de piratage qui commencent par l’exploitation d’une faille complexe, nécessitant des compétences techniques pointues. Et puis il y a celle du ministère de l’Intérieur : comme le révèle une enquête du journal Le Monde, tout aurait commencé avec l’ordinateur personnel d’un fonctionnaire du ministère de l’Agriculture, un logiciel d’édition musicale et un malware. De là à arriver aux fichiers de la police nationale, il y a normalement un gouffre. Normalement. C’est beau… mais plein de courants d’air. Image Ministère de l’Intérieur. Tout commence le 19 septembre 2025. Un fonctionnaire du ministère de l’Agriculture travaillant en Bourgogne consulte depuis chez lui sa messagerie professionnelle. Il suit alors un lien vers un faux site proposant des logiciels d’édition musicale. Mauvaise pioche : son ordinateur personnel se retrouve infecté par Rhadamanthys, un « infostealer », autrement dit un logiciel malveillant dont la spécialité consiste précisément à aspirer les informations intéressantes présentes sur la machine : données de navigation, identifiants, sessions et autres informations d’authentification. Déjà se pose le premier souci : le fonctionnaire a des privilèges assez élevés sur l’infrastructure du ministère, et le bon sens voudrait qu’il ne consulte pas sa boîte professionnelle à partir d’un ordinateur personnel, surtout si celui-ci lui sert à télécharger des logiciels « douteux ». Mais bon. Parmi les données récupérées se trouvent les identifiants professionnels du fonctionnaire. Mais les pirates ne s’arrêtent pas là : ils accèdent également à son Google Drive personnel, dans lequel l’agent avait stocké son certificat d’authentification permettant de se connecter au VPN du ministère de l’Agriculture. Une clé professionnelle stockée sur un service cloud personnel, lui-même accessible depuis un ordinateur personnel compromis : une clé aussi importante sur un compte Google Drive, sérieusement ? Deuxième faute. Une fois dans le réseau du ministère, les pirates prennent possession du compte de l’agent, qui dispose de droits importants du fait de ses fonctions liées à l’informatique et aux statistiques agricoles. Et personne ne semble les déranger : ils peuvent se promener pendant plusieurs semaines dans le système d’information de l’Agriculture. Là, la faute change de camp : comment une intrusion informatique dans les serveurs d’un ministère peut rester non détectée pendant plusieurs semaines ? Troisième faute. De l’Agriculture à la police : cloisonnement ? C’est quoi ça ? Le 9 novembre, les intrus découvrent une passerelle reliant le réseau du ministère de l’Agriculture à celui de l’Intérieur. Non, le fonctionnaire initial n’avait donc pas un compte donnant directement accès aux systèmes de Beauvau. Mais la compromission d’un ministère permet néanmoins de trouver un chemin vers un autre. Cloisonnement efficace ? Non. Quatrième faute, et magnifique celle-là. Les pirates disposent alors de presque un mois (oui, un mois !) pour découvrir l’architecture du réseau de l’Intérieur et, notamment, les serveurs de la Direction générale de la police nationale. Une faille dans un outil interne accessible depuis un navigateur leur permet ensuite de prendre le contrôle de comptes de gestionnaires de messagerie de plusieurs directions de la police. Ces comptes disposent notamment de la possibilité de réinitialiser les mots de passe d’autres agents. Et hop, cinquième faute. Ça commence à faire beaucoup ? Ne vous inquiétez pas, c’est loin d’être fini. Une fois dans les messageries de policiers, les pirates recherchent des certificats permettant de se connecter au VPN du ministère de l’Intérieur. Et ils en trouvent, tranquillement stockés en pièces jointes d’e-mails. Mieux encore : les mots de passe associés se trouvent dans le corps des messages correspondants. Certificat et mot de passe au même endroit, donc. Pratique pour l’utilisateur… et pour le pirate : l’équivalent du post-it sur le moniteur, version 2.0. Sixième faute… Grâce à ces éléments, les attaquants finissent par accéder à Cheops, le portail utilisé par policiers et gendarmes, sans même avoir besoin de carte professionnelle sécurisée. Ils peuvent alors consulter le fichier des personnes recherchées (FPR), mais également le traitement des antécédents judiciaires (TAJ). Selon les chiffres communiqués par le ministre de l’Intérieur, 23 fiches et 3 000 éléments de sommaires du FPR ont été dérobés, ainsi que 72 fiches et plusieurs dizaines de milliers de sommaires issus du TAJ. Une fiche Interpol a également été récupérée. Plus embarrassant encore, les pirates ont pu consulter plusieurs procédures judiciaires en cours. Pas de 2FA sur Cheops, accès facile : septième faute. Le compte est bon. Quand toutes les barrières tombent les unes après les autres Laurent Nuñez avait évoqué au moment de la découverte du piratage un « manque d’hygiène numérique » de certains agents. Difficile de lui donner entièrement tort : stocker un certificat VPN professionnel dans un Google Drive personnel ou envoyer un certificat par e-mail avec son mot de passe dans le message ne devrait probablement figurer dans aucun manuel de bonnes pratiques. Même tatie Danielle, on essaie de lui donner de meilleures protections pour les photos de ses chats. Mais réduire l’affaire à quelques fonctionnaires imprudents serait passer à côté de l’essentiel. Un utilisateur finira toujours par cliquer au mauvais endroit. C’est précisément pour cette raison que les systèmes sensibles disposent normalement de plusieurs couches de protection indépendantes. « Normalement ». Ici, l’ordinateur à l’origine de l’intrusion était un appareil personnel. Qui dit BYOD dit potentiellement absence de maîtrise complète du parc : impossible pour l’administration de garantir de la même manière les mises à jour, la présence et la configuration des outils de sécurité, les logiciels installés ou encore les droits accordés à l’utilisateur. Le BYOD peut être sécurisé à l’aide d’outils de gestion et de politiques strictes, mais laisser des données d’authentification sensibles sur un terminal personnel en réduit sérieusement l’intérêt. L’accès aux serveurs d’un ministère, même la simple boîte mail, ne devrait pas pouvoir se faire à partir d’un appareil personnel, quel que soit le grade du fonctionnaire. Vient ensuite le cloisonnement : la compromission du ministère de l’Agriculture n’aurait pas dû faciliter à ce point un rebond vers celui de l’Intérieur. Une interconnexion entre administrations peut parfaitement avoir une justification professionnelle, mais elle ne devrait en aucun cas permettre une escalade de privilèges menant aux clés du coffre contenant les données les plus précieuses. Un coût d’investissement pourtant raisonnable, non ? Image MacGeneration. Enfin vient l’authentification : des certificats VPN accompagnés de leurs mots de passe ont suffi à poursuivre l’intrusion jusqu’à des systèmes contenant certaines des données les plus sensibles détenues par l’État. Le 2FA ? Connaît pas ? Apparemment non : il a fallu que la catastrophe arrive pour qu’enfin quelqu’un ait l’ingénieuse idée de l’imposer pour accéder à un portail qui donne sur des informations aussi importantes que le fichier des personnes recherchées. La chaîne complète laisse songeur : un PC personnel infecté mène à un Google Drive personnel, puis au VPN de l’Agriculture, au réseau du ministère, à une passerelle vers l’Intérieur, aux comptes de messagerie de policiers, à de nouveaux certificats VPN et finalement à Cheops, au FPR et au TAJ. Encore une fois, au total, 72 fiches TAJ, plusieurs dizaines de milliers de lignes de sommaire, 23 fiches FPR, 3 000 éléments associés, mais aussi dix fiches Interpol consultées et une téléchargée. Sept applications métier sur 150 ont été consultées, heureusement sans modifications ni destructions. Mais le tableau est plutôt moche. Piratage des services de l’État : Sébastien Lecornu annonce la contre-attaque Le premier ministre Sébastien Lecornu reconnaissait mercredi que « peu de ministères [étaient] au niveau requis » en matière de cybersécurité. Au vu de l’itinéraire emprunté par les pirates, difficile de lui donner tort. Et au vu des failles béantes, les pirates s’en donnent maintenant à cœur joie.

_tldr: the live version is here:https://curl.se/perf/_ How fast is “fast” and is it good enough? Does it run as fast now as it did before or was there a regression? What exactly needs to be fast? How fast is it? These are questions that many projects and products face, and in curl we are no different. Yet, performance testing and comparisons are _hard_ and full of landmines and time-wasting efforts. For many years we have occasionally brought up the idea of a performance test suite for curl only to shut it down again because the challenges seemed hard and no one was volunteering to do this. This week it changed. ## Let’s do this I started out trying to find existing projects that host performance results for Open Source projects so that we could just feed our results something else and get great visualizations and data management. I did not find any such. I then took a look at what existing tools there are for this purpose, and most pointers seemed to suggest that Grafana is a popular and maybe even a good solution to build something like this with. But man, that is a complicated machine and it felt more than a little overwhelming just figure out where or how to start with it. I decided to postpone that take as well. ## Let _me_ do this I decided that instead of trying to do this the best and optimal way – I shouldn’t let perfect be the enemy of good – I would start out by doing the things I know how to do and take it as far as I can one step at a time. _Something should be better than nothing_. Performance testing needs decently stable system conditions so that repeated runs produce reasonably similar results, when all involved factors remain identical. This is basically impossibly to accomplish using most cloud infrastructure since those are almost always shared with countless other users. At least on the cheap and free tiers we use. We probably need our own dedicated hardware for this, but instead of trying to figure out where to get that and arrange for that, I would start by running performance tests on my own local development machine. I am a single user on this and it has many cores and runs decently fast. It should be good enough to get this going on. I created a first shell script that updates the curl source code from git, it configures and builds it. Then it runs a bunch of tests, outputs a bunch of data and logs all the output in a single log file. I started out with a few simple tests. How fast does curl download a 100 GB file from localhost, how many allocations and how big allocations does it need for a single HTTP download? My second script parses all the test log files from the previous builds and generates summaries and graphs for them. To make it possible for humans to see how the performance changes between builds and ideally to automatically detect when something changes more than what should be tolerated. As I am a graph addict already since before, and that journey has taught me a little gnuplot, I decided that even while there probably are much better tools and fancy JavaScript things that _could_ be used, I don’t know them and learning them now is an endeavor I rather avoid. So I stick to what I know and can get results with quickly. I third script is invoked from a crontab every twenty minutes, sets up some variables and invokes the runner script. Once the basics started to work, I showed my curl friends the early versions and I soon created a new git repository for the code. ## It’s live baby After a little more poking, I soon made my locally produced performance test summary get packaged and automatically transferred to the curl website after each build, and voila, the first public curl performance tests were live and public. Getting this data available immediate triggered curl developers. It only took hours until we had the first proposed changes to improve some numbers, and soon we had a few merges to that affect. Visibility really helps! The performance numbers we get are still varying to a certain degree, partially of course because I still use my machine for my daily development things, but also because most of them do real (localhost) networking and that is by its nature a little… _varying_. The system builds and runs a new round every twenty minutes and it does that using the latest commits from git. This setup makes it sometimes run many rounds on the same commit and it might also mean that it sometimes updates and get several new commits at once, so it might skip a round for some commits. I might reconsider this design later, but since it is still a twenty minute time window, the number of commits is still limited. When the script makes multiple build rounds on the same commit, it accumulates the numbers and for the graph it stores the maximum, the median and the minimum value. It helps show the variation per commit and allows us to cram more into the graphs. It is still early days, but there will be a maximum limit to how many commits that can be displayed in a single graph and still be helpful. HTTP/2 parallel download speed through 31 build rounds ## Distribution To help visualize the distribution and data spread per test, I created a separate illustration that shows the Minimum, maximum, P25, P75, Medium and Mean values in a _Box-and-Whisker Plot_. A Box-and-Whisker Plot showing the HTTP/2 parallel download speed data distribution. ## Changing conditions An obvious downside with me just storing build logs in files, is that it will not scale up to the millions. I did however decide that I’m not designing this system for that. At least not now. Performance tests are highly specific and dependent on the exact machine it runs on, the exact third party libraries and their versions that are used, the other components involved in the tests, such as the servers, and more. I expect that we will change conditions for the tests every once in a while that makes it hard to compare the current numbers with past numbers or at last hard to do much about the differences. Therefore I think the performance test numbers and values are primarily useful in the short term. To help us spot if we land something that subtly and _unintentionally_ degrades something. ## Stakes To detect extremely slow and long-term changes in performance and even making sure we can better survive wiping all the existing build logs etc, I introduced a concept I call _stakes_. As in a stake pole. A marker. An arbitrary threshold set manually for each specific test. This value can be used to measure performance test results against, now and later. As conditions change and maybe something makes the results go up or down and we are fine with those changes because they are motivated and expected, then we just change the stakes. If it works out, I might the system automatically detect and maybe highlight tests that deviate too much from its set stake (at least if done in the _wrong_ direction) . It could be a signal that something bad was merged. ## Balances As with everything in life, things are often balanced out. We already ran into this when we eagerly merged several changes to reduce the number of allocations to do a single HTTP download, only to realize that one of the optimizations we did had the side effect that it expanded the size one of the main structs. Changes in one area might come at an expense in another. With sufficient tests and data we can improve curl for users, and at the same time make sure that our improvements don’t come with a cost we are not prepared to pay. Exactly how to make the balance is of course a question we need to deal with, discuss and decide. Possibly for whatever change we do. ## The tests As I write this, we have 24 tests and a full test round completes in about six minutes on my machine. We can of course do multiple builds using different hardware, different operating systems, different build options, different third party libraries and different test servers to check more angles of performance, and I am certainly open for and prepared to do that going forward. I will however first let this single-flavor run for a while so that we get more data, get a change to tweak it and make it as usable as possible for curl developers. As with everything there is no end to what we _can_ make this do. This is a start. I sure we can take it further as we move along. In particular if people join in and help out. Both with ideas and proposals for visualizations, graphs and new tests to add, but also with actual pull-requests and code. ## Build volumes and graphs Over the last year, we have merged, on average, about 10 commits per day. If we keep this pace up and this performance test setup can show 100 commits conveniently into a single graph, that is just ten days of development. Probably not enough. Once we reach one hundred builds or so in the first graphs I need to consider adding separate _long term_ graphs that use select data-points to display data development over a longer time. Some googling told me the Largest-Triangle-Three-Buckets, or LTTB for short, is a fine algorithm to use for this. I now do a separate “long term” graph that “downsamples” the full range down to something that can be shown in a reasonable way. I suppose we will see properly in the future how this works. ## Spotting change The _stake_ thing I mentioned is one way to help us spot gradual performance changes over time. Another googling told me that there’s a _Mann-Kendall Test + Sen’s Slope_ algorithm to use to identify trends in graphs like this and it can be used to plot a trend. It might work as a helper to better identify… yeah, the data _trend_ for each test. The HTTP/2 parallel download speed trend at a specific moment ## Developing This setup has only existed for a few days. There is lots to do, lots to learn and much more to experiment with. Your comments, help and pull-requests will be appreciated!

In the afternoon of August 5 2019, I successfully made curl request a document over HTTP/3, retrieve it and then exit cleanly again. (It got a 404 response code, two HTTP headers and 10 bytes of content so the actual response was certainly less thrilling to me than the fact that it actually delivered that response over HTTP version 3 over QUIC.) The components necessary for this to work, if you want to play along at home, are reasonably up-to-date git clones of curl itself and the HTTP/3 library called quiche (and of course quiche’s dependencies too, like boringssl), then apply pull-request 4193 (build everything accordingly) and run a command line like: `curl --http3-direct https://quic.tech:8443` The host name used here (“quic.tech”) is a server run by friends at Cloudflare and it is there for testing and interop purposes and at the time of this test it ran QUIC draft-22 and HTTP/3. The command line option `--http3-direct` tells curl to attempt HTTP/3 immediately, which includes using QUIC instead of TCP to the host name and port number – by default you should of course expect a HTTPS:// URL to use TCP + TLS. The official way to bootstrap into HTTP/3 from HTTP/1 or HTTP/2 is via the server announcing it’s ability to speak HTTP/3 by returning an Alt-Svc: header saying so. curl supports this method as well, it just needs it to be explicitly enabled at build-time since that also is still an experimental feature. To use alt-svc instead, you do it like this: `curl --alt-svc altcache https://quic.tech:8443` The alt-svc method won’t “take” on the first shot though since it needs to first connect over HTTP/2 (or HTTP/1) to get the alt-svc header and store that information in the “altcache” file, but if you then invoke it again and use the same alt-svc cache curl will know to use HTTP/3 then! ## Early days Be aware that I _just_ made this tiny GET request work. The code is not cleaned up, there are gaps in functionality, we’re missing error checks, we don’t have tests and chances are the internals will change quite a lot going forward as we polish this. You’re of course still more than welcome to join in, play with it, report bugs or submit pull requests! If you help out, we can make curl’s HTTP/3 support better and getting there sooner than otherwise. ## QUIC and TLS backends curl currently supports two different QUIC/HTTP3 backends, ngtcp2 and quiche. Only the latter currently works this good though. I hope we can get up to speed with the ngtcp2 one too soon. quiche uses and requires boringssl to be used while ngtcp2 is TLS library independent and will allow us to support QUIC and HTTP/3 with more TLS libraries going forward. Unfortunately it also makes it more complicated to use… The official OpenSSL doesn’t offer APIs for QUIC. QUIC uses TLS 1.3 but in a way it was never used before when done over TCP so basically all TLS libraries have had to add APIs and do some adjustments to work for QUIC. The ngtcp2 team offers a patched version of OpenSSL that offers such an API so that OpenSSL be used. ## Draft what? Neither the QUIC nor the HTTP/3 protocols are entirely done and ready yet. We’re using the protocols as they are defined in the 22nd version of the protocol documents. They will probably change a little more before they get carved in stone and become the final RFC that they are on their way to. ## The libcurl API so far The command line options mentioned above of course have their corresponding options for libcurl using apps as well. Set the right bit with CURLOPT_H3 to get direct connect with QUIC and control how to do alt-svc using libcurl with CURLOPT_ALTSVC and CURLOPT_ALTSVC_CTRL. All of these marked EXPERIMENTAL still, so they might still change somewhat before they become stabilized. ## Update Starting on August 8, the option is just `--http3` and you ask libcurl to use HTTP/3 directly with CURLOPT_HTTP_VERSION.

Migrer une application déployée avec Kustomize vers Helm pose un problème méconnu : Helm repose sur des annotations et labels de propriété que les …

The Kubernetes SIG Network community is thrilled to share the release of Gateway API v1.6.0, which was released on June 30th of this year! Gateway API has become the standard for modern, role-oriented,...

At this exact moment curl’s summer of bliss 2026 ends. We (the maintainers of curl) took the entire month of July off from vulnerability reporting and in this post I will try to explain how this went. (If you feel like skipping the wordy blab below, the single word answer is: _fine_) **This was possibly our best project decision in a long while.** ## Zero vulnerability reports Already before this, we have been refusing to answer emails about vulnerabilities. Partly because we can’t keep track of them that way but even more so because it makes it much harder to properly disclose and publish the entire report sequence after the fact. On our Hackerone page we informed visitors that we were on pause and that they could come back in August. We had I believe _one_ vulnerability report sent to my private email address in this period in spite of that messaging, but for all intents and purposes this worked out exactly as good as we hoped it would. I just ignored that email. That was easy. ## Bliss The effect was almost immediate. Just a few days into the bliss, my fellow curl maintainers all agreed with me that we felt a sense of relief, of vacation and that a load had been taken off our chests. We felt free, _unchained_ , and now suddenly able to do what we wanted. We could now spend time reviewing some of the queued up pull-requests for features and changes we like. We could suddenly again work on code in areas we had been leaving behind lately as vulnerability reports sucked all the air out the room. We polished details on the website, we found document gaps to tighten. It felt like the good old days again. The _fun_ days. We got reminded why we do Open Source and how fun it is. We took time off, saw some other corners of the world and enjoyed some time away from the keyboards. We truly healed and re-energized. ## CNA Before we took off on the bliss, we were informed in clear terms that the CNA rules (we are a CNA) mandate that we must respond within 72 hours for some critical vulnerabilities so we can’t just ignore them. I told them sure we can, but in the worst case case our “root” could do some emergency assignments. I figured the risk was minimal and it turns out I was right, Nothing like that was needed and no CVE assignments were necessary during the bliss. ## Customers I got a curious question or two from existing support customers on how the bliss would affect them, but that was easy: it did not affect them. Now, post-bliss, I think they all can confirm that it really did not. ## New customers? As I promised to keep up the contact with and support for paying customers even during the bliss, you could possibly imagine that this would have been an incentive for worried commercial curl users out there to sign up for support contracts. This did not happen – at all. By this I think we should conclude that (commercial) curl users were not worried either. ## The outside world Lots of fellow open source maintainers and most people in my surrounding have been super positive and downright supportive of our _taking some time off_. I can’t recall having receiving a single negative comment about the curl summer of bliss! ## Fellow blissers I was moved to see that several other Open Source projects followed our example and also took some time off in order to recharge and relax. In addition to giving us a little vacation, it helps sending a signal and a reminder that Open Source is to a large extent done voluntarily and even maintainers need a break at times. ## Major incidents? Have we opened ourselves up for dangerous attacks and flaws now? Have the bad guys an edge on all curl users out there now because we lived in bliss for a month? We don’t know yet, but it would surprise me. ## Queues During this slow-down, we slowly got more open issues and pull-requests lingering on GitHub than usual. No surprise there. Once we started to come back to life again, we have since managed to return them back to the normal amounts. ## Flood gates Yes, there is an obvious risk that there are now a whole range of queued up reports that will hit us in a short period time as we open up for vulnerability reports again. Presumably the risk for duplicates among these reports should also be significantly higher than usual. I suppose I need to do an update post in a month or two and let you know what happened. We always treat vulnerability reports and project security with topmost priority and we will continue to do so. We will simply work with what we have and make sure our users and by extension, the world, are safe. Since I am a member of a few other (non-curl) security teams that did not have a summer of bliss, I have seen that the flood of vuln reports have not really slowed down so it might depend a lot on the details of each specific project. ## Some emails were read All individual curl maintainers of course handled this gift in their own ways. We did not all just disconnect to sit on a remote beach for the whole time. Some of us did that part of the time, but we mostly enjoyed the lower stress level and the absence of pressure. It was mentally relaxing. So, even if some of us kept up with emails, occasionally responded to issues or even submitted some pull requests of our own, it was still vacation. It was still blissful. ## Rebliss? Will we do another summer/winter of bliss? I think yes. It was simply great, with virtually no downsides for the people involved but instead lots of positiveness. Ideally a reduced workload going further will remove the need for another one, but it is not easy to tell what the future holds. ## Just transfers After all, curl just does transfers. Fast. Reliably. Secure.

If you strike me down, I shall become more powerful than you can possibly imagine. ©Obi-Wan

Éviter la prolifération de LoadBalancers avec Envoy Gateway : la feature mergeGateways pour partager un seul Service LB entre plusieurs Gateways d'un cluster Kubernetes.

Servir une page de maintenance par défaut sur une Envoy Gateway, en HTTPS, même sans FQDN, grâce aux certificats Let's Encrypt sur adresse IP via le profil shortlived.

[1.0.2] - 2026-07-27 Changed Bump module version to 1.0.2 Upgrade AsBuiltReport.Chart module to version 0.3.4 Fixed Fix #264 Fix #260 Fix critical issue preventing report execution. Fix cmdlet C...

Mozilla is hiring a Necko Student Worker in Remote Canada, Firefox, New Products, Firefox, Core Services, Firefox, Mozilla Foundation, Core Services, Mozilla.org, New…

See also: day one, day two. There is only one thing that is better than two days of HTTP workshop, and that is of course _three_ days of HTTP workshop. The final day of this edition of the series started out with us again shuffling around where we parked ourselves around the big table. Except Mr captain of course who once again got to herd us forward through another day from the same seat. ## **Why MOQ is going to replace HTTP live streaming** MOQ (Media over QUIC transport) is not HTTP, but it uses QUIC so it is at least tangentially interesting and it involves a lot of the same people so this status update still felt welcome and suitable. Compared to existing HTTP based solutions, MOQ is supposed to offer less complexity and lower latency. The moon landing was broadcasted with less latency than current live-streamed TV and maybe MOQ can make us come close to those numbers again. In MOQ clients subscribe to a track that then contains a lot of objects that are delivered. It’s not the request + response approach of HTTP. The fact that this is not HTTP of course brings a lot of questions and well, doubts, and we lingered on various aspects of this topic for quite a while. ## **Reverse HTTP** My prize for the best slides of the HTTP workshop 2026 goes to [redacted] for the excellent use of potato images in their presentation. PTTH is HTTP spelled backwards, commonly pronounced as PoTaToH. A client sets up the connection but the actual HTTP request is sent from the server to the client. One of the intended use cases for this, is to allow an origin server to connect to the CDN proxy and then be able to deliver traffic to the world, rather than to have the CDN connect to the origin the way they usually do. Apparently most CDNs already have custom and proprietary solutions for exactly this kind of feature, so maybe doing it in a standard way instead makes sense? ## **Resumable uploads** The draft explains the new proposed way to continue a previously interrupted upload over HTTP. The upload request gets a Location: header back for the resource being uploaded, and if it gets stopped prematurely, a client can then HEAD that resource, figure out the size and then do a second upload (using the PATCH method) request that tells the server that this transfer should start at offset X. Exactly how this should be supported in browser’ upload forms seemed a little bit uncertain.For my own sake I can see a challenge to implement this nicely for curl in particular when the upload is using formpost upload (curl’s -F flag) which after all still is a very common way to do uploads on the current web. I’ll return to this topic at a later time when I written an implementation to test… ## **io_uring vs. multithreaded server runtimes vs HTTP mismatch** io_uring is a Linux asynchronous I/O framework that avoids the overhead of traditional system calls. It uses two shared ring buffers between user space and the kernel, allowing applications to batch I/O operations with zero-copy efficiency. The feature is disabled by Google in ChromeOS, Android and in production Google servers which certainly holds back some use of it. io_uring can be helpful to speed up things, but might be complicated to use in existing software architectures and the presentation went into some details on why this is so. ## **Modern UDP I/O for Firefox in Rust** A walk-through of some of the recent developments and improvements in Firefox’s UDP networking stack. Going from single datagrams to the modern ways to ship large chunks of data offloaded to the kernel to speed things up. Upload throughput in Firefox is up 60-90% over the last 11 releases. Lots of fun graphs and metrics were shown. This work is based on the quinn-udp stack. ## **Rollout of Happy Eyeballs v3 in Firefox** Happy Eyeballs v3 is coming and Firefox is implementing it. It now takes into account many more data sources than before, including alt-svc and HTTPS-RR and races connections against each other to use the one that connects first. There are some recommended timers in the specification and parts of the discussion was around how maybe the timers could instead be tightened a bit, and maybe the delay between the subsequent attempts could then use an exponential backoff instead sticking to a fixed interval? (I know I’ll discuss some of these details with my curl hacker friends and see what we should adjust… curl already supports most of the Happy Eyeballs v3 specification.) ## **Shorter ones** As we approached the end of the day a few shorter topics were ventilated to give us a little more to consider before going home: * Why is there no UTF8 in URIs? “If we would do it again, we would have allowed UTF8 in there” was said by someone who was there in the mid 1990s… * Optimistic DNS is a draft. Use stale DNS cache data while getting the new. Connection remains alive for 120 seconds while DNS data is often not cached for even 30 seconds. No one in the room seemed to hate it. Let’s do this! * The journey to QUERY. One of the primary authors of the RFC took us through what it took to make it happen. It was sixteen years since the most previous registered HTTP method and maybe this was the last one ever? ## **The end** for this time With this, the seventh HTTP workshop had ended. Again a very fine event. This time graciously sponsored and arranged by Adobe. Thank you everyone! The general idea is to continue with these events roughly every second year and I support this. The HTTP workshops are definitely one of my favorite events. ## Credits The top image on this post was used in the final presentation and the author told me he is aware of the AI errors in there, “of which there are at least two”.

If you missed it. I already described day one. Caffeinated and ready, we all gathered in the same spacious room as yesterday, but seated in new places as “suggested” by our captain. Some of us even remembered to move over the name tags we wrote yesterday to our new seats. No time was wasted on introductions today. We dove straight in at the deep end. ## **How AI is changing how HTTP is implemented**. Is the future of software that we check-in the AI prompts in the git repository and trust it to generate the correct code? Are specifications the new level o f abstraction for source code? These questions triggered long discussions with a huge mix of opinions and experiences getting shared about how AI is used, should be used and could be used now and in the future. ## **Observations and Measurements of HTTP/2 During Large-Scale Web Crawls** The Common Crawl spidering upgraded to using HTTP/2 for their scan and as an end result, I believe 61% of the responses used HTTP/2 and the entire round ended a few percent faster than before, which when you traverse a few billion URLs really makes a difference. They apparently use a locally patched version of Apache Nutch for this. ## **HTTP/1.1 behavior divergence** The HTTP probe project runs a lot of tests on HTTP/1 servers and compares how they behave in a lot of different aspects and then generates these awesome tables. Looks like something for every server implementer team to have a look at and decide what of these red boxes that should rather be converted into green alternatives. ## **Request smuggling test suite** _HTTP Zoll_ is a new**** test suite for intermediaries that tests intermediaries (what we often call proxies) for a large amount of request and response smuggling issues. Some real world problems found were discussed and as this project aims at going Open Source words were expressed on what kind of precautions and checks that maybe should be done first. I hope we get to hear more about this project soon. ## **Server performance & measurement** The HTTP Arena is another project that does performance and measurements. They test HTTP server frameworks and present the results in various ways on their site. ## **Increase and evolve HTTP/3 & QUIC** In this presentation, we were presented with different HTTP/3 deployment numbers from different sources and the associated reasoning around why they differ but then more importantly. what can and should be done to increase HTTP/3 usage. Anti-virus interceptions, enterprise blocks and server-side performance not yet on par with TCP were mentioned as reasons for holding back the numbers. Reasons for using HTTP/3 include use cases that encourage QUIC adoption: WebTransport, Media over QUIC and MASQUE (HTTP/3 proxies and HTTP/3 proxies over older HTTP proxies). Using HTTPS-RR for upgrade was promoted, as every alt-svc response that is returned with an ALPN using h3 should perhaps also offer h3 over DNS. Why doesn’t your server announce its h3 support over HTTPS-RR? QUIC v2 is deployed on an amazing 0.003% of all QUIC v1 domains and there was a discussion why this is so and the common sentiment in the room seemed to be that very few saw a reason for deploying v2 and several expressed a concern that doing so might in fact introduce issues. Someone (you can probably guess who) in the room increased that number a lot by quietly mentioning that haxproxy.org certainly supports it. ## **QMUX** QUIC multiplexing over bi-directional streams is a proposal on how to do QUIC-style multiplexing over TLS (or anything else really). It has been adopted by the IETF QUIC working group and there was a somewhat extended discussion about what the HTTPbis group should or should not do with it. The biggest interest might be for data center use, but is that then something IETF should bother about? This is not the first time I blog about this, and even if there did not seem to be a strong demand or need for this, it also did not seem to be completely dead. I bet we will hear more about this later. ## **Multiplexed proxying: challenges in H2 and H3** Doing a TLS terminating MITM proxy has its challenges and we were given some insights and experiences on the challenges of doing HTTP/2 and HTTP/3 to the server. The browsers refuse to do HTTP/3 when they detect custom CA certs installed, which apparently is mostly because of lots of past bad experiences with anti-virus software that in particular seems to break QUIC and for users it is not obvious where the blame should go. This then makes browsers not do HTTP/3 over any MITM proxy. Some time was spent on how allowing different clients to the proxy uses a shared h2 connection to the target server is complicated and not used, even though in theory it should be possible. An argument was made that it could even lead to worse performance than when using HTTP/1 but I could not quite follow that reasoning. I’m sure I missed some subtle detail in that explanation. ## **Making the Web QUICer with Rapid Start** When the afternoon is running late and we have been promised beer and snacks after the final talk, what is better than a hard core technical presentation with lots of graphs and numbers showing how QUIC performance can be improved by tweaking the congestion control algorithm and send more data in the startup phase of a new QUIC connections? This new approach is called Rapid Start and it looks like a promising and yet simple improvement. According to experiments done on real world traffic, the time to last byte was reduced by 14.7% on average. Not bad at all. ## **Drinks and food** Our meeting sponsor Adobe graciously sponsored drinks and food so we got to linger around for a few extra hours and talk even more HTTP and networking until the personal firmly insistent they needed us to leave the room and we instead continued solving world problems elsewhere. Topics around the table included the famous HTTP/2 spec coin flip, the QUIC spin bit, the SCONE situation for QUIC, the timeline behind the QUERY method and many more great stories. Thanks for the beer! Now we can’t wait for day three.

An occasional gathering of HTTP experts to discuss the Web’s foundational protocol.

Nous allons load balancer un ping avec XDP

Mon cheminement pour autoscaler un cluster OVH déployé via la Cluster API, en utilisant Karpenter et son provider cluster-api, avec MKS comme cluster de management.

Pester is the ubiquitous test and mock framework for PowerShell.

Wireshark: The world's most popular network protocol analyzer

[1.0.5] - 2026-07-08 🔃 Changed Update module version to v1.0.5 🐛 Fixed Fix critical issue preventing report execution. Closes #262

[1.0.4] - 2026-07-03 🔃 Changed Update module version to v1.0.4 Bump AsBuiltReport.Diagram module to v1.0.8 Bump AsBuiltReport.Chart module to v0.3.4 Update github actions to latest releases Valida...

Le rolling release d’Arch Linux peut casser. Avec BTRFS et Timeshift, vous pouvez revenir en arrière en quelques minutes. Voici comment automatiser les snapshots et restaurer votre système.