I want to discuss some approaches to HTTP3, specifically related to negotiating and timing.
As I see it there are three approaches for implementing HTTP3. Each with their own pros and cons
- Start with HTTP over TCP and upgrade to QUIC over UDP via Alt-Svc header. The already negotiated key will be transferred over via PSK extension to share the pre negotiated key. This is the way most browsers implement HTTP3 and fits what your library is trying to accomplish. However, it will also leave more traces due to the double fingerprinting taking place (first HTTP2/1.1 and then HTTP3).
- A happy eyeballs approach that starts HTTP3 and HTTP2/1.1 in parallel and go with what responds first. This will also cause double fingerprinting.
- Start with HTTP3 and wait for a response. If no response fallback to HTTP2/1,1. This will imitate a browser that has cached the result of a Alt-Svc header with HTTP3 support beforehand.
Another (4:th) option is to delegate the strategy of negotiating to the users of the rnet library via configuration. For example a HTTP3 strategy parameter that the user can provide with options like: HTTP3 only, HTTP2 only, HTTP3 browser like, HTTP3 happy eyeballs, HTTP3 with fallback, etc..
Which option do you think is the best?
I want to discuss some approaches to HTTP3, specifically related to negotiating and timing.
As I see it there are three approaches for implementing HTTP3. Each with their own pros and cons
Another (4:th) option is to delegate the strategy of negotiating to the users of the rnet library via configuration. For example a HTTP3 strategy parameter that the user can provide with options like: HTTP3 only, HTTP2 only, HTTP3 browser like, HTTP3 happy eyeballs, HTTP3 with fallback, etc..
Which option do you think is the best?