Hacker News Reader

Comment by metadat | Hacker News Reader

With HTTP/1.1 you can debug a request via an ASCII telnet session. Not feasible with QUIC.

HTTP/1.1 has a beautiful, elegant, simplistic essence; super easy to implement servers and clients from scratch with literally no dependencies beyond string formatting and basic TCP network APIs.

View on HN

You can debug it because the telnet tool and the kernels TCP stack reassemble a lot of binary TCP and IP frames for you. If they wouldn't, you would have a much harder time looking at it.

A QUIC library (or proxy) which reassembles all streams and just sends presents you the stream contents would allow you to run HTTP/1.1 over a QUIC and you have the same visbility. Just replace netcat with a hypothetical quiccat. Now obviously this would bring you not that much value for a real world deployment, since browsers and other tools don't do HTTP/1.1 over QUIC but prefer binary HTTP/3 over QUIC. But the comment about "use a tool that gives you a readable representation" still applies. You can use curl to get a readable request/response, browser dev tools. And if you need more insight, qvis (https://qvis.quictools.info) is pretty awesome.

You can effectively debug unencrypted HTTP using tcpdump, no reassembly usually required because a request with headers and a response headers fit one IP packet. If they don’t, someone uses way too big headers (or too many).

Given most sites still support HTTP/1.0, it's very unlikely we'll see anyone drop http/1.1 for another three decades, at least. Especially when you factor in how slow some large chunks of the world are to upgrade their OSes and software suites.

> Given most sites still support HTTP/1.0

Uh, HTTP 1.0 doesn't support the host header, which means that you need unique IP addresses for each host you want to serve.

Ironically, you could solve that problem with IPv6, but...

Reply on news.ycombinator.com