The first HTTP/3 code landed in #curl in 2019. Now we might soon have it enabled for real and not "experimental" anymore: curl.se/mail/lib-2023-10/0023.…
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…
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.
@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.
@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.
daniel:// stenberg://
in reply to daniel:// stenberg:// • • •The "#OpenSSL situation" will still make it tricky for ordinary people to enable HTTP/3.
As I blogged already two years ago: daniel.haxx.se/blog/2021/10/25…
The QUIC API OpenSSL will not provide | daniel.haxx.se
daniel.haxx.seNoratrieb
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
in reply to Noratrieb • • •Ondřej Surý
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
in reply to Ondřej Surý • • •Stefan Eissing
in reply to daniel:// stenberg:// • • •Ondřej Surý
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
in reply to Ondřej Surý • • •Richard Levitte
in reply to daniel:// stenberg:// • • •@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.
daniel:// stenberg://
in reply to Richard Levitte • • •@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ý
in reply to daniel:// stenberg:// • • •vsz
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
Unknown parent • • •