Maximilian Hils

All good. I appreciate you opening this issue, just letting you know I won't find the time to tackle it soon. :)

Good point - I think we should fail visibly and exit with an error on a failed write. Optionally we can also consider checking `shutil.disk_usage` on top and exit at...

I'm not sure which project you are referring to (mitmproxy has more recent commits), but of course you can work on this. :)

https://github.com/mitmproxy/mitmproxy/blob/main/mitmproxy/addons/save.py is the starting point - I don't have any further capacity to mentor at the moment, sorry.

mitmproxy now at least exits on a full disk. Truncating the file back to its previous length isn't trivial unfortunately, calling `f.truncate(pos)` on a full disk just raises another `disk...

I'd be happy to merge a PR that implements this in a reasonably simple manner, but it's nothing I'd be actively pushing myself. As a workaround, one can always use...

No, there is currently no workaround.

That's definitely something that's on our radar. The changes involved are quite nontrivial, but @Meitinger has a working fork with QUIC support at https://github.com/Meitinger/mitmproxy. We will probably take a closer...

QUIC remains a bit tricky to implement for us. - Ideally we'd use OpenSSL, but OpenSSL still does not expose reasonable APIs (https://daniel.haxx.se/blog/2021/10/25/the-quic-api-openssl-will-not-provide/). - One alternative is aioquic, which I'm...

> @mhils Do you have a ballpark for what sponsoring that effort would cost? It might be helpful for conversations in organizations that depend on mitmproxy but are longing for...