3 ms·

HTTP/3-only will not be a thing in the foreseeable future. One major reason is that clients actually need knowledge that a website supports HTTP/3. And how do t

HTTP/3-only will not be a thing in the foreseeable future. One major reason is that clients actually need knowledge that a website supports HTTP/3. And how do they obtain that knowledge? It's over a HTTP/1.1 or HTTP/2 request which returns the Alt-Svc: h3 header. It will probably take decades until Alt-Svc over DNS (DNS-SVB) is fully specified and universally supported - and only after that websites can drop HTTP/x over TLS support. HTTP/3 is also just 50% as CPU efficient as TCP based HTTP versions, so using it doesn't make sense for every use-case. Also even if HTTPS is forced, it doesn't mean HTTP is dead. HTTP is still the protocol we are running over a TLS connection, so it's here to stay.

EwanToo 3y ago
Or they just optimistically connect to both TCP/443 and UDP/443, create both a HTTP/1 and HTTP/3 connection in parallel, then see which one responds quicker. This already happens with some major apps.
- Matthias247 3y ago
  Some might indeed do. According to my knowledge from testing 1 year ago it's mostly Safari that is doing this. Other browsers follow the specification and require Alt-Svc information.
  - EwanToo 3y ago
    I'm not sure the specification says what you describe, it doesn't in my reading. I don't believe Alt-Svc is required, and as you say Safari is behaving this way already. https://www.rfc-editor.org/rfc/rfc9114.html#section-3.1-3 https://www.rfc-editor.org/rfc/rfc9114.html#section-3.1-3 Discovering an HTTP/3 Endpoint A client MAY attempt access to a resource with an "https" URI by resolving the host identifier to an IP address, establishing a QUIC connection to that address on the indicated port (including validation of the server certificate as described above), and sending an HTTP/3 request message targeting the URI to the server over that secured connection. Unless some other mechanism is used to select HTTP/3, the token "h3" is used in the Application-Layer Protocol Negotiation (ALPN; see [RFC7301]) extension during the TLS handshake. Connectivity problems (e.g., blocking UDP) can result in a failure to establish a QUIC connection; clients SHOULD attempt to use TCP-based versions of HTTP in this case.
    - Matthias247 3y ago
      This seems correct. But as the spec says, some services might run HTTP/3 on a different port than 443 - e.g. for load balancing purposes. Those setups would fail if clients just try to connect to 443.
GoblinSlayer 3y ago
>until Alt-Svc over DNS (DNS-SVB) is fully specified and universally supported Don't they already have hardcoded DoH?
- Matthias247 3y ago
  DNS over HTTP is something different than Service Discovery over HTTP (https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/ https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https...). The latter is plain DNS, but allows to transfer alternate service responses as part of the DNS response packet. As you can see from the link, it's still in a draft state.
  - GoblinSlayer 3y ago
    If they have their own DoH, it can send them any response format. http3 drafts are supported in the wild too.

EwanToo 3y ago

Or they just optimistically connect to both TCP/443 and UDP/443, create both a HTTP/1 and HTTP/3 connection in parallel, then see which one responds quicker. This already happens with some major apps.

Matthias247 3y ago
Some might indeed do. According to my knowledge from testing 1 year ago it's mostly Safari that is doing this. Other browsers follow the specification and require Alt-Svc information.
- EwanToo 3y ago
  I'm not sure the specification says what you describe, it doesn't in my reading. I don't believe Alt-Svc is required, and as you say Safari is behaving this way already. https://www.rfc-editor.org/rfc/rfc9114.html#section-3.1-3 https://www.rfc-editor.org/rfc/rfc9114.html#section-3.1-3 Discovering an HTTP/3 Endpoint A client MAY attempt access to a resource with an "https" URI by resolving the host identifier to an IP address, establishing a QUIC connection to that address on the indicated port (including validation of the server certificate as described above), and sending an HTTP/3 request message targeting the URI to the server over that secured connection. Unless some other mechanism is used to select HTTP/3, the token "h3" is used in the Application-Layer Protocol Negotiation (ALPN; see [RFC7301]) extension during the TLS handshake. Connectivity problems (e.g., blocking UDP) can result in a failure to establish a QUIC connection; clients SHOULD attempt to use TCP-based versions of HTTP in this case.
  - Matthias247 3y ago
    This seems correct. But as the spec says, some services might run HTTP/3 on a different port than 443 - e.g. for load balancing purposes. Those setups would fail if clients just try to connect to 443.

GoblinSlayer 3y ago

>until Alt-Svc over DNS (DNS-SVB) is fully specified and universally supported Don't they already have hardcoded DoH?

Matthias247 3y ago
DNS over HTTP is something different than Service Discovery over HTTP (https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/ https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https...). The latter is plain DNS, but allows to transfer alternate service responses as part of the DNS response packet. As you can see from the link, it's still in a draft state.
- GoblinSlayer 3y ago
  If they have their own DoH, it can send them any response format. http3 drafts are supported in the wild too.