Dirkjan Ochtman
Dirkjan Ochtman
Happy to take suggestions on how we could change the API to be more amenable for your requirements.
I don't love this. It feels like a kludge to retrofit low-level needs into a high-level API. I think we should make a proper low-level API and rebuild the high-level...
> > I don't love this. It feels like a kludge to retrofit low-level needs into a high-level API. I think we should make a proper low-level API and rebuild...
> As a result, I am forced to run multiple server instances, each with its own set of registered sockets, which is inefficient and cumbersome. What exactly about this is...
@gretchenfrage you mentioned you want to review this -- friendly ping?
> That said, providing an avenue to expose application state in a `CONNECTION_CLOSE` reason might be against the spirit of this text. I agree. Going to close this. @gretchenfrage thanks...
I'm giving up on this for now. Disabling the broken test in - #199
> More specifically, we need to know if any Error occurred during cert verification, so that we can decide whether to proceed with the connection later on. Can you more...
Have you looked at the [`Acceptor`](https://docs.rs/rustls/latest/rustls/server/struct.Acceptor.html) API? That let's you provide a `ServerConfig` based on the same `ClientHello` type that is used as input for `ResolvesServerCert::resolve()`.
Right -- that would be https://github.com/quinn-rs/quinn/issues/2024.