HTTP/3 seems to be around the corner, already implemented in most web browsers (may be off by default), makes web browsing much faster. It’s based on QUIC protocal (which IS DONE), then UDP, not TCP of TCP/IP (so it’s going to be much less used overall soon).
For some code, e.g. clients (even Julia’s own Pkg [manager] in Base?), HTTP/3 and QUIC might be very important, as in if Julia doesn’t catch up to it will be slower. On the server side, you can e.g. use @essenciary’s Genie.jl (and/or Stipple.jl) to implement websites. Since Genie builds on already existing web servers, it seems only them need to/already do(?) support HTTP/3, so I’m not too worried. I believe Genie (and some other Julia software) may work as a full web server, if configured that way (non-default?) then not needing any non-Julia web server [code]. Then it would be slower, using HTTP/1.1, not even HTTP/2 (which Julia seemingly can skip implementing).
Franklin.jl (e.g. used for julialang.org) makes static web sites, so it’s immune, i.e. also defers to web servers software, that can/does implement HTTP/3.
(For clients), it’s unclear Julia needs Julia-only implementations of HTTP/3 or QUIC. It seems like a lot of work, and not worth it to do more than wrap already existing implementations. Not sure such a wrapper should be in Base (e.g. for Pkg, or the download function). I believe Julia already uses curl, and it has those protocols.
Pkg uses Downloads which uses libcurl, so once curl supports HTTP/3 we will automatically be able to use it as well. Pkg servers will have to be upgraded to support HTTP/3 as well before it matters, but they use an nginx frontend, so that will also be doable. HTTP.jl is a separate, pure Julia implementation of the HTTP protocol, so that’s an entirely different story. Someone will have to implement HTTP/3 in the package if they want it to work.
Oh, I’ll note that it’s pretty unusual on the server side not to have something like nginx in front of the actual application server, so it may not matter if Genie or whatever else supports HTTP/3: it can just serve HTTP/1 or HTTP/2 and let nginx (or whatever other caching proxy goes in front of it) handle serving HTTP/3.
Note that one of the big selling points of HTTP/3 is to support multiplexed downloads of multiple files over a single UDP connection. To exploit this we will need to use the curl multi API, but it looks like we are already doing this?
(CURLPIPE_MULTIPLEX is enabled by default in curl ≥ 7.62 for use with HTTP/2, and presumably this will use HTTP/3 once it is available.)
It is not enabled at build time currently. I’d be ok with enabling it in the libcurl build but disabling it by default unless explicitly turned on for a request by passing the relevant options to libcurl. I really don’t feel like feel like being guinea pigs for experimental http/3 support. The benefits do not outweigh the potentially issues at this point.