HTTP is a protocol that’s foundational for data exchange on the web.
It allows communication between browsers and servers, but it can also be used for machine-to-machine communication, automating access to APIs, and more.
On MDN, the HTTP section has over 300 pages of reference material, and the majority of pages are about HTTP headers and response status codes.
Response status codes let the client know the outcome of a HTTP request (such as 200, 404), and give some additional context in certain cases.
There are 61 status codes documented on MDN and they include examples for common responses and clarifications for rarer types that web developers may not encounter often.
You can even make sure you’re familiar with the 418 (I’m a teapot) status just in case.
There are 148 HTTP headers documented on MDN.
HTTP headers are the parts of the HTTP message that carry metadata, information about the client or server, instructions for the recipient, and so on.
Some headers have several sub-pages that describe mechanisms you can control via headers, such as Content Security Policy (CSP) directives that instruct a browser to restrict what the code comprising a site can run and Permissions Policy directives for requesting permission to use browser features such as location or microphone access.
The HTTP guides have overviews of how the protocol works, describing the evolution of the protocol from HTTP/0.9 right through to current versions.
We document different ways to control HTTP interactions such as caching and conditional requests, and we have guides about how to use and understand the protocol for beginners, right up to more involved topics.
A lot of the refresh of these guides meant making less specific references to HTTP/1.1 when talking about message formats seeing as HTTP/2 and HTTP/3 are increasingly common.
HEAD /en-US/docs/Web/HTTP HTTP/2
Host: developer.mozilla.org
User-Agent: curl/8.7.1
Accept: */*
* Request completely sent off
HTTP/2 200
To summarize, the changes we made across the entire HTTP section included adding examples where they were missing or too short to be useful, removing outdated or obsolete information, and making the formatting and presentation consistent over all pages.
HTTP highlights on MDN
Part of the refresh involved updating and adding sequence diagrams that explain client-server exchanges.
We’ve been finding mermaid syntax useful for a lot of these types of diagrams as it makes it easier to store sources for images that we may need to update later.
These images are stored in the shared-assets repository, which allows us to reuse images instead of duplicate them in the source, and these are easier to write, read, maintain, and they look nice, too:
One interesting pick from the HTTP section is the Server-Timing response header that you can use to surface server metrics to a client:
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 123
Date: Fri, 03 Jan 2025 10:41:21 GMT
Server-Timing: custom-metric;dur=123.45;desc="My custom metric"
--- response body ---
Depending on the type of request, you can decide if you want to send server timings to the client, and these are visible in the Network request details panel in most browser’s developer tools.
For example, the BBC iPlayer is using the Server-Timing header to send performance metrics about the service, visible in the Network > Timings panel below.
If you find this interesting, be sure to check the Performance API and the Web performance documentation.
For the HTTP section, most of the BCD updates involved improving the accuracy of existing entries and adding missing compat data for headers.
Additions included the Service-Worker request header for logging service worker script requests and the Sec-Websocket-* headers used in the WebSocket handshake.
Most of the HTTP updates are for older features, but the accuracy of the support information is crucial for developers making decisions about what to build.
One example is the Trailer compatibility details which now reflects browser implementations.
It’s important to avoid misleading information in compatibility tables because they may encourage people to develop functionality in their applications for features that have poor browser support in reality.
