Re: wget2 | Implement HTTP/3 support using QUIC (#553)

[Momoka Y (@momoka0122y)]

Momoka Y commented on a discussion: 
https://gitlab.com/gnuwget/wget2/-/issues/553#note_807887204

> my questions would be: can they be disconnected ? If not, we just need a 
> quic.c that handles both layers.

QUIC and TLS can't be disconnected so I guess it does make sense to put them in 
the same file.


> How do we know that a server (or connection) supports (or requests) transport 
> via QUIC ?

I don't think there is a way to "know" if a server supports QUIC in advance.
In a simple implementation wget will try to access a server via QUIC (when 
there is a command line option to do so) but if the sever does not support QUIC 
it should fail. (like the --http2-only option)

Ultimately we should have a TCP and a QUIC connection race in parallel (when 
there is a command line option to enable http3) and when the QUIC handshake 
fails use the TCP connection instead.

draft Applicability of the QUIC Transport Protocol states the necessity of 
fallback.
https://www.ietf.org/archive/id/draft-ietf-quic-applicability-13.html#name-the-necessity-of-fallback


> For the latter we can then think of a persistent cache (e.g. a file like 
> `.wget-hsts`)
Making a cache file seems outside of wget's job so I think we will need to try 
QUIC without knowing if it will fail or not. 

Also since the network path will change depending on the network a computer is 
connected to there may be middle-boxes (firewalls) on a certain path that 
blocks UDP (rare but possible) so having a persistent cache may not be 
practical.

-- 
Reply to this email directly or view it on GitLab: 
https://gitlab.com/gnuwget/wget2/-/issues/553#note_807887204
You're receiving this email because of your account on gitlab.com.