David Pedersen

I think I'm gonna experiment with some sort of builder that doesn't panic.

I'm curious what your use case is. Maybe just writing a custom middleware from scratch is easier? I'd like to avoid making `AsyncAuthorizeRequest` more complicated than it already is.

I suppose not.

From https://github.com/tower-rs/tower-http/issues/125 > @Nehliin @MarcusGrass and I (all work at embark) and have talked about this a bit. We think given the number of unanswered questions here not gonna include...

We already have a small example client [here](https://docs.rs/tower-http/latest/tower_http/index.html#example-client). The main thing missing is boxing it so its easier to name the type, without having to spell out the large type....

This has been requested before but the question has always been how to handle unsupported encodings. About `content-encoding` [the spec](https://httpwg.org/specs/rfc7231.html#header.content-encoding) says > An origin server MAY respond with a status...

I think we have to add a new middleware. Changing the trait bounds like that is a breaking change.

Assuming that the user would never construct these themselves then I like `IncomingBody`.

> I noticed that ConcurrencyLimit allows mutations to itself in both poll_ready() and call() to update the permit which means concurrent accesses would cause race conditions Can you elaborate on...

I've looked into this a bit and don't think its easy to solve unfortunately. `.route_with_tsr("/a", get(handler))` does two things: 1. It adds a regular router for `/a` that calls your...