Jake Goulding

> Should this still be open Yes, I think so, as the problem still occurs. > Is there an action to take? With modern Rust, you can avoid importing/exporting the...

My thoughts... 1. Investigate the `catch` handler, but it looks like it doesn't accept arguments at the moment: https://github.com/carllerche/tower-web/blob/533da53d7e429492d93ad550ac2c62507b6a5488/tower-web-macros/src/resource/catch.rs#L16-L17 Adding that support seems like it would be welcomed, based on...

It could be that the `Error` of a handler should always be `tower_web::Error` and represent "real hard failures". Then this instead this could be: ```rust fn something(&self, path: String) ->...

> a `SendFile` response type My first thought was that this was for [using the HTTP header](https://www.nginx.com/resources/wiki/start/topics/examples/xsendfile/) when behind another server. I think *both* implementations can be valuable. > a...

> a framework And I'd expect a framework to provide an abstraction over these (`x-real-ip` || ... || TCP address). > no concept of an IP address (like UDS). Great...

Could even provide a helper thing: ```rust let m = middleware::maybe(some_bool, || { // create middleware here }) ```

> a helper thing: I say this, but as far as I can tell you either leak the type: ```rust fn maybe(enabled: bool, f: impl FnOnce() -> M) -> Either...

> Middleware will be moved into a dedicated crate tower-web requires `M: HttpMiddleware`; so this tailored for that case. Do you expect this new crate to be beyond tower-web? Will...

The playground [guesses via filename](https://github.com/integer32llc/rust-playground/blob/tower-web/ui/src/tower_web_server.rs#L164), so I'm in favor. I had trouble trying to implement this in a reusable manner, however (although I don't remember why).

> passing in a type that conditionally enables or disables the middleware Heh, this makes me think I should add `MaybeMiddleware(M)` so that all middleware can use the same implementation....