Maximilian Hils

Honestly it feels like we should just swallow the error in `broadcast` [here](https://github.com/mitmproxy/mitmproxy/blob/73c38f698d42002947e46294498b2166f3139cf4/mitmproxy/tools/web/app.py#L292-L295) and be done with it.

Can we maybe just do OCSP Stapling instead of dealing with CRLs?

Hi @Sanqui! I'm on the go, but here's the very short high-level version: You can find our HTTP client playback code in https://github.com/mitmproxy/mitmproxy/blob/main/mitmproxy/addons/clientplayback.py. https://mitmproxy.org/posts/new-proxy-core/#layers has a bit of background on...

Thanks. It looks like your mitmproxy is outdated. Could you please upgrade an try again?

refs https://github.com/mitmproxy/mitmproxy/issues/5166#issuecomment-1066122544

I ran into the same problem and what worked for me was to explicitly specify types: ```rust let records = vec![record]; let response = MessageResponseBuilder::new( Some(request_message.raw_queries()) ).build( header, Box::new(records.iter()) as...

Ok, it is actually mentioned in the OpenSSL docs that a blocking socket may raise a SSL_ERROR_WANT_READ... > If the underlying BIO is blocking, SSL_read() will only return, once the...

> I'd be entirely happy to re-add the setting-by-default behavior if you also > want to add a unit test for it. Thanks again. Any hints how could get that...

We have a workaround for pyOpenSSL 0.14 in the latest mitmproxy/netlib master - I haven't gotten around writing a proper test case yet and fix this upstream, sorry.

I tried implementing this using a memory BIO, but I'm stuck at this point. No matter whether I specify `SSL_MODE_AUTO_RETRY`, I always get a `WantReadError` if I try to `recv()`...