Detecting HTTP Version...
Please wait while we analyze your connection.
🐌 You are using HTTP/1.0
The classic HTTP protocol from 1996. I see you have an eye for vintage software.
📡 You are using HTTP/1.1
The longtime workhorse of the web. Reliable and ubiquitous, though starting to show its age.
🚀 You are using HTTP/2
A binary, multiplexed upgrade over HTTP/1.1. If you refresh this page, your browser may upgrade to HTTP/3 via the Alt-Svc header or the HTTPS DNS record.
✨ You are using HTTP/3
Congratulations! You're on the cutting edge, using HTTP over QUIC + UDP.
❓ You are using ???
Could not detect a recognized HTTP version header (for example, when previewing locally without the Cloudflare edge worker). You can test specific states using ?version=HTTP/3 or ?version=HTTP/2.
🔄 Dynamically detected: This result is read live from the edge connection your browser used to fetch this page. Try refreshing or testing with curl below!
📊 Connection & Request Details
Here is the connection metadata seen at the edge for your browser's request:
💡 Fun Fact: It took multiple requests for your browser to upgrade to HTTP/3. Browsers often discover HTTP/3 support via the Alt-Svc response header on the initial HTTP/2 connection.
| 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
🛡️ RPKI Check
Is your ISP BGP safe? This check tests whether your ISP filters invalid BGP route announcements using RPKI by fetching resources from both validly and invalidly signed prefixes (powered by isbgpsafeyet.com).
✨ HTTP/3
HTTP/3 replaces TCP with QUIC, a multiplexed transport protocol built over UDP with TLS 1.3 integrated directly into the handshake. Because each stream is independent at the transport layer, a lost UDP packet only stalls the single stream it belongs to—eliminating transport-layer head-of-line blocking.
Browsers typically discover HTTP/3 support in two ways:
- Alternative Service (
Alt-Svc) header: A server sendsAlt-Svc: h3=":443"on an HTTP/1.1 or HTTP/2 response so subsequent connections upgrade to QUIC on UDP port 443. HTTPSDNS record: A DNS record advertisingalpn="h3"alongside the IP address, allowing the browser to speak HTTP/3 on the very first request.
🚀 HTTP/2
HTTP/2 replaced plain-text lines with a binary framing layer and introduced stream multiplexing, HPACK header compression, and flow control over a single TCP connection.
This solved HTTP-layer head-of-line blocking, though a single lost TCP packet still stalls all active streams at the OS kernel level until retransmitted.
📡 HTTP/1.1
HTTP/1.1 made persistent connections (Keep-Alive) the default so browsers could reuse a single TCP connection across multiple requests, and added chunked transfer encoding for streaming responses of unknown length.
Because responses must still be returned strictly in order on each connection, a slow response holds up every queued request behind it (HTTP head-of-line blocking).
🐌 HTTP/1.0
HTTP/1.0 introduced the anatomy we recognize today: status codes (200 OK, 404 Not Found), request and response headers (Content-Type, Content-Length), and methods like POST and HEAD.
Without persistent connections by default, every single image or stylesheet required a fresh TCP three-way handshake.
📜 HTTP/0.9
The original 1991 one-line protocol: no headers, no status codes, and only a single method (GET /path). The server wrote back raw HTML bytes and immediately closed the TCP connection.