Richard Bradfield

Thanks for continuing to investigate this, based on what you've added so far, I suspect request ordering is at fault, it could be that depending on the browser, it might...

Unfortunately I'm not able to reproduce this when I wrap `examples/hello-world.rs` in a server built with `new_ssl()`, so a snippet that exhibits the issue would be really helpful. I tested...

~I'm starting to suspect the changes in https://github.com/tiny-http/tiny-http/pull/151 are related.~ The PR references fixing a deadlock, but at least at first glance it doesn't look like it should have been...

It turns out it was unfair to blame https://github.com/tiny-http/tiny-http/pull/151! The PR description is inaccurate, it refers to the TLS Socket accept call being that which holds a lock preventing the...

To what extent should the above (timeouts + deadlines) be the responsibility of the underlying HTTP server `tiny-http` and what parts should be handled by the web framework itself? `tiny-http`...

I'll need to take a look and see what if any requirements there are for changing over - thanks for the note!

I think it's pretty reasonable to close this as "Not appropriate" for Rouille - if you want to go down the route of Async programming for your webserver then there...

Thanks for the report @MightyPork - I tend to agree that switching to a maintained provider of `Content-Encoding: multipart/*` is probably the better solution than carrying around vendored or patched...

This is, unfortunately, more trouble than it initially seemed. `Multipart` and `buf_redux` are direct dependencies and thus fairly easy to swap out, indeed someone already maintains [an updated version of...

> Is it possible to make `multipart` an optional feature instead? Not everyone needs `Content-Encoding: multipart/*` for their applications. Yes, but doing so is a breaking change and requires a...