Detecting HTTP Version...
Please wait while we analyze your connection.
🐌 You are using HTTP/1.0
The original HTTP protocol from 1996. I see you have an eye for vintage software.
📡 You are using HTTP/1.1
The most widely used HTTP version. It's the reliable workhorse of the internet, but it's starting to show its age.
🚀 You are using HTTP/2
A major upgrade that's faster and more efficient. If you refresh this page, there's a chance you might connect with HTTP/3 instead! This is caused by the Alt-Svc header or the HTTPS DNS Entry being read by your browser.
✨ You are using HTTP/3
Congratulations! You're on the cutting edge, using the fastest and most modern HTTP protocol available.
❓ You are using ???
Well, this is unexpected. You're using a version of HTTP that this page doesn't recognize. Maybe you're from the future, or maybe something's a little off. Either way, consider me impressed!
🔄 This content is dynamically generated based on your actual HTTP connection. Try refreshing the page or opening it in different browsers to see how the protocol varies!
📊 More Info
By the way, here is more information that is revealed about you from the request your browser made:
💡 Fun Fact: It took multiple requests for your browser to connect with HTTP/3. This is common as browsers often discover HTTP/3 support via headers like Alt-Svc
on the first few connections.
HTTP Version | |
---|---|
IP Address | |
ASN (?) | |
City | |
Postal Code | |
Country | |
Continent | |
Geo Coordinates | |
Time Zone | |
User Agent |
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
✨ 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 anAlt-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.