Skip to main content

The first HTTP/3 code landed in #curl in 2019. Now we might soon have it enabled for real and not "experimental" anymore: https://curl.se/mail/lib-2023-10/0023.html

Curl: HTTP/3 towards non-experimental

curl.se
#curl
in reply to daniel:// stenberg://

daniel:// stenberg://
daniel:// stenberg://
• •

The "#OpenSSL situation" will still make it tricky for ordinary people to enable HTTP/3.

As I blogged already two years ago: https://daniel.haxx.se/blog/2021/10/25/the-quic-api-openssl-will-not-provide/

The QUIC API OpenSSL will not provide | daniel.haxx.se

daniel.haxx.se
#OpenSSL
in reply to daniel:// stenberg://

Nilstrieb
Nilstrieb
• •
rustls supports the necessary APIs (but the C API overall is still experimental) đź‘€
in reply to Nilstrieb

daniel:// stenberg://
daniel:// stenberg://
• •
@nilstrieb ... and having the API is just one step, someone also needs to make ngtcp2 use that API so that curl can do QUIC and HTTP/3 over it...
@Nilstrieb
in reply to Ondřej Surý

daniel:// stenberg://
daniel:// stenberg://
• •
@ondrej No. quictls, boringssl, wolfssl, GnuTLS, aws-lc etc are all solutions for this. OpenSSL does not feature the necessary APIs without a patch.
@Ondřej Surý
in reply to daniel:// stenberg://

Stefan Eissing
Stefan Eissing
• •
@ondrej nginx has made a workaround that seems to support everything but Early Data. Have not looked at the details.
@Ondřej Surý
in reply to daniel:// stenberg://

Ondřej Surý
Ondřej Surý
• •
BIND 9 needs MPL2.0 compatible license, PKCS#11 and QUIC API. So we are pretty much stuck between rock and the hard place. On top of that, there are customers where a security (and/or compliance) need to rubber stamp any library used on the production systems…
in reply to Ondřej Surý

daniel:// stenberg://
daniel:// stenberg://
• •
I feel for you. I'm sure you are far from alone in such an unfortunate situation. I blame #OpenSSL for not caring much about their users.
#OpenSSL
This entry was edited (6 months ago)
in reply to daniel:// stenberg://

Richard Levitte
Richard Levitte
• •

@ondrej

Depends on what you think "caring about your users" actually is.

OpenSSL has figured that an OpenSSL-native API, integrated with already existing OpenSSL API, is important, and likewise, it's important to be able to build OpenSSL on quite a lot of platforms with a minimum of dependencies.

BTW, OpenSSL has achieved the client part by now. I'm tempted to contribute a patch that uses this... given personal time.

@Ondřej Surý
in reply to Richard Levitte

daniel:// stenberg://
daniel:// stenberg://
• •

@levitte @ondrej I don't' think OpenSSL took that decision for its users. I think openssl did it in an attempt to increase its value in the "food chain" or something. Because it would have been super easy and friction free to do both, but OpenSSL explicitly decided to not provide what users asked for for years and instead provide what no users asked for...

But sure, this is just my own personal view. I have no actual insights.

@Ondřej Surý @Richard Levitte
in reply to daniel:// stenberg://

Ondřej Surý
Ondřej Surý
• •
@levitte The fact is that people want us to implement DoQ and we simply can’t. Or we can, but it’s going to be mess both for developers and users alike.
@Richard Levitte
⇧