4 ms·

HTTP 3? Oh, you mean the thing that used to be HTTP-over-QUIC, another “standard” unilaterally declared by Google :-)

superkuh 4y ago
I'm with ya, but it wasn't just google. Google easily convinced the other megacorps like Microsoft that QUIC was good for their use cases and together they managed to whitewash it through the IETF. It wasn't just google. But it is just mega-corps. QUIC is a bad standard for human persons but excellent for corporate persons. As for webtransport, this is the first time I'm hearing of it. My browsers definitely don't support it.
- kmeisthax 4y ago
  >QUIC is a bad standard for human persons but excellent for corporate persons. ...er, why? It keeps packet loss from slowing down site loading (as much as is possible). I'm not sure how this is "bad for human persons".
  - jrockway 4y ago
    I think that most of the objection is that with HTTP/1.1 you can type "telnet example.com 80" and type out an HTTP request and read the reply. I see similar arguments about why JSON is better than protocol buffers. All the necessary keys are on your keyboard. At the end of the day, I just write a tool to do these binary-exchanges for me. If I need to send a protocol buffer message to some server, I just write a program to do that. It's 3 lines of code. If I do it a lot, I check it in and write documentation. There are plenty of reusable generic mechanisms that already exist, too. curl for all of your HTTP request needs. OpenAPI to make an app that talks to your custom API. People tend to draw the line exactly at their current level of understanding. A few years ago, people would say "SSL is only for corporations", but with Let's Encrypt, you don't see that come up anymore. They're comfortable not having keys on their keyboard that can do the TLS handshake, because they now understand the server-side and client-side tooling, and the obscurity of a binary protocol they can't type out is no longer an impediment to productivity. Soon, they'll be comfortable with HTTP/3 as well.
  - superkuh 4y ago
    You can't use QUIC without CA based TLS. There do not exist CAs run by human persons that have root certs in popular browers. They are all run by incorporated entities. It is bad that a human person trying to connect to another human person cannot do so without the continuing approval of a third party corporate person. For companies and institutions this requirement makes perfect sense. It's a great protocol for doing business. But for human people it introduces yet another layer of centralizing complexity for legal and social pressures to be applied and abuses to be enforced. It also makes setting up a webserver even more complex forcing more centralization in hosting. And not that anyone cares, but you can't legally use QUIC over amateur radio like you can HTTP or even HTTPS with a null cypher self signed cert.
    - WHATDOESIT 4y ago
      Let's Encrypt doesn't work with HTTP 3 or what do you mean? Human persons need strong encryption much more than legal persons. Legal persons can't die/have their health damaged/be thrown in prison/be lynched by a mob. This is a way to make it available to everyone. It's not hard to setup your CA and add a profile with it if you just want to communicate with other human persons and it must be HTTP 3. Of course browsers don't include random humans' CAs... I am happy about that. And why don't you just use HTTP 1/2 over amateur radio? That your 0.0000001% usecase (don't tell me you yourself do it more often) isn't supported doesn't mean the whole thing is bad.
seabrookmx 4y ago
gQUIC != QUIC, though it definitely inspired it (the same way SPDY inspired HTTP/2). QUIC went through the IETF and HTTP/3 is supported in all modern browsers now. It also has a lot of technical advantages over previous versions. Google doesn't always do the right thing but I haven't heard a solid argument over why their contributions to QUIC and HTTP/3 are bad.
intelVISA 4y ago
I just want QUIC over QUIC (QUICly) but I don't have the same lobby power over the IETF sadly.

I'm with ya, but it wasn't just google. Google easily convinced the other megacorps like Microsoft that QUIC was good for their use cases and together they managed to whitewash it through the IETF. It wasn't just google. But it is just mega-corps. QUIC is a bad standard for human persons but excellent for corporate persons. As for webtransport, this is the first time I'm hearing of it. My browsers definitely don't support it.

kmeisthax 4y ago
>QUIC is a bad standard for human persons but excellent for corporate persons. ...er, why? It keeps packet loss from slowing down site loading (as much as is possible). I'm not sure how this is "bad for human persons".
- jrockway 4y ago
  I think that most of the objection is that with HTTP/1.1 you can type "telnet example.com 80" and type out an HTTP request and read the reply. I see similar arguments about why JSON is better than protocol buffers. All the necessary keys are on your keyboard. At the end of the day, I just write a tool to do these binary-exchanges for me. If I need to send a protocol buffer message to some server, I just write a program to do that. It's 3 lines of code. If I do it a lot, I check it in and write documentation. There are plenty of reusable generic mechanisms that already exist, too. curl for all of your HTTP request needs. OpenAPI to make an app that talks to your custom API. People tend to draw the line exactly at their current level of understanding. A few years ago, people would say "SSL is only for corporations", but with Let's Encrypt, you don't see that come up anymore. They're comfortable not having keys on their keyboard that can do the TLS handshake, because they now understand the server-side and client-side tooling, and the obscurity of a binary protocol they can't type out is no longer an impediment to productivity. Soon, they'll be comfortable with HTTP/3 as well.
- superkuh 4y ago
  You can't use QUIC without CA based TLS. There do not exist CAs run by human persons that have root certs in popular browers. They are all run by incorporated entities. It is bad that a human person trying to connect to another human person cannot do so without the continuing approval of a third party corporate person. For companies and institutions this requirement makes perfect sense. It's a great protocol for doing business. But for human people it introduces yet another layer of centralizing complexity for legal and social pressures to be applied and abuses to be enforced. It also makes setting up a webserver even more complex forcing more centralization in hosting. And not that anyone cares, but you can't legally use QUIC over amateur radio like you can HTTP or even HTTPS with a null cypher self signed cert.
  - WHATDOESIT 4y ago
    Let's Encrypt doesn't work with HTTP 3 or what do you mean? Human persons need strong encryption much more than legal persons. Legal persons can't die/have their health damaged/be thrown in prison/be lynched by a mob. This is a way to make it available to everyone. It's not hard to setup your CA and add a profile with it if you just want to communicate with other human persons and it must be HTTP 3. Of course browsers don't include random humans' CAs... I am happy about that. And why don't you just use HTTP 1/2 over amateur radio? That your 0.0000001% usecase (don't tell me you yourself do it more often) isn't supported doesn't mean the whole thing is bad.

seabrookmx 4y ago

gQUIC != QUIC, though it definitely inspired it (the same way SPDY inspired HTTP/2). QUIC went through the IETF and HTTP/3 is supported in all modern browsers now. It also has a lot of technical advantages over previous versions. Google doesn't always do the right thing but I haven't heard a solid argument over why their contributions to QUIC and HTTP/3 are bad.

intelVISA 4y ago

I just want QUIC over QUIC (QUICly) but I don't have the same lobby power over the IETF sadly.