📊 More Info

Below you will find descriptions of each version with a list of significant features added. I also wrote a post about this page. Feel free to read it here.

You can get this same information with the command line like so:

curl --http1.0 https://kmcd.dev/http/ -Is | grep x-kmcd

Here’s an example using curl’s HTTP/3 support (requires a specific build of curl)

$ curl --http3 https://kmcd.dev/http/ -Is | grep x-kmcd-http-request-version
x-kmcd-http-request-version: HTTP/3

🛡️ RPKI Check

Is your ISP BGP safe? This tool checks if your ISP is filtering BGP routes based on RPKI by attempting to fetch resources from both valid and invalidly signed prefixes. This is built using the same endpoints as isbgpsafeyet.com. Go there for more information.

fetch https://valid.rpki.isbgpsafeyet.com
... loading ...
fetch https://invalid.rpki.isbgpsafeyet.com/
... loading ...

✨ HTTP/3

HTTP/3 improves upon HTTP/2 by using QUIC, a new transport protocol built on UDP. This finally eliminates head-of-line blocking entirely and allows for zero round-trip time (0-RTT) connection resumption.

This could lead to seamless network switching in the future, for example, moving from Wi-Fi to cellular without a noticeable interruption.

Browsers can discover HTTP/3 support in two main ways:

  • Alternative Service (Alt-Svc) header: The server can send an Alt-Svc header in an HTTP/1.1 or HTTP/2 response to indicate that HTTP/3 is available on a specific host and port.
  • HTTPS DNS record: A newer method involves a special HTTPS DNS record that signals HTTP/3 support directly, allowing a browser to connect using HTTP/3 on the very first request.

🚀 HTTP/2

HTTP/2 introduced a binary encoding format, making it more compact and efficient to parse. Its biggest feature was multiplexing, which allows multiple requests and responses to be sent in parallel over a single connection using "streams".

This solved the head-of-line blocking at the HTTP level, but the problem still existed at the TCP level.

📡 HTTP/1.1

HTTP/1.1 solved the connection problem by introducing persistent connections, allowing multiple requests to be sent over a single TCP connection. It also added chunked encoding, which allows a response to be sent in pieces.

While a huge improvement, it still suffered from head-of-line blocking, where a slow request could hold up all the requests behind it.

🐌 HTTP/1.0

This version brought many of the features we recognize today, including request methods (like GET and POST), HTTP headers for passing metadata, and status codes to indicate the outcome of a request.

However, it required a new TCP connection for every single request, which was inefficient and slow.

📜 HTTP/0.9

The simplest protocol, HTTP/0.9, had no headers, status codes, or even different request methods. A request was a single line, and the server's response was just the HTML file.