3 ms·

Not educated on this, but whats the problem with it?

metadat 3y ago
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.
- judge2020 3y ago
  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.
  - henrikschroder 3y ago
    > 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...
- Matthias247 3y ago
  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 https://qvis.quictools.info) is pretty awesome.
  - citrin_ru 3y ago
    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).

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.

judge2020 3y ago
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.
- henrikschroder 3y ago
  > 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...
Matthias247 3y ago
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 https://qvis.quictools.info) is pretty awesome.
- citrin_ru 3y ago
  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).