Mark Nottingham
Senior Principal Engineer, Fastly
Mark Nottingham has helped to define and develop the web and the internet since the late 90s. He's written, edited, or substantially contributed to more than 30 IETF RFCs and W3C recommendations about topics like HTTP, caching, linking, web architecture, privacy, and security. As chair of the the HTTP Working Group since 2007, he has overseen the evolution of the foundational protocol of the web, notably including HTTP/2. As chair of the QUIC Working Group, he oversaw the creation of HTTP/3 and the evolution of internet transport. He has also served in internet governance bodies, including the Internet Architecture Board and the W3C Technical Architecture Group. Currently, he’s part of the Office of the CTO at Fastly, and studying Communications Law at Melbourne Law School. Mark is married to Anitra with two sons, Charlie and Bennet. They live in Melbourne, Australia.
Minimizing ossification risk is everyone’s responsibility
Building protocols in a way that anticipates future change in order to prevent ossification is critical. Because it’s impossible to upgrade everyone on the internet at the same time; it needs to be possible to introduce changes gradually, without harming communication where only one party understands the change — and this is everyone’s responsibility.
Exploring 103 Early Hints Beyond Server Push | Fastly
Many people think that the 103 Early Hints HTTP status code can help web performance in certain situations, but we won’t know until we get data about it, and without that data, browsers won’t support it. If your site has content like that described in this post, please consider joining this experiment.
What is Cache Control?
The Cache-Control response header is one of HTTP’s more widely known header fields; it allows a site to control how caches handle their data in CDNs, browsers, and elsewhere
Improving HTTP with structured header fields
The HTTP community has been busy modernizing the web’s protocol over the last decade, with multiple revisions of the core specification, a number of extensions, HTTP/2, and now HTTP/3. Unfortunately, the way we define and use HTTP header fields hasn’t changed much since the beginning, with underspecified headers (and lots of different ways to handle them) causing interoperability issues, developer pain, and even security problems. But help is coming.
Creating standards for CDNs
Content delivery networks (CDNs) have been around for a long time, but they’re not all built in the same way. While Fastly’s edge cloud platform goes beyond traditional content delivery networks by moving things to the edge, there are more fundamental differences; it’s not uncommon for CDNs to make up their own rules about how they serve web traffic, since CDNs didn’t exist when HTTP was defined. To improve this, we’re working alongside other platforms to standardize basic protocol handling for CDNs.
Testing HTTP freshness in CDNs
CDNs all use HTTP caching to optimize performance, but sometimes different CDNs do it in slightly different ways and that can make things more complicated for our customers. This blog post makes a case for CDN interoperability and introduces a common test suite to help identify differences between CDNs to start paving the way.
