You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
I wish to make a route / filter that is enabled based on command line argument.
However, I find it is kind of cumbersome to have a filter optionally enabled.
I can currently find 3 solutions:
boxing filter and assigning to variable
letmut f = base_filter().boxed();// invoked with --with-extra-featureif args.with_extra_feature{
f = f.or(extra_filter()).unify().boxed();}
f = f.or(other_filters());
However, this requires coercing filter to the same exact type, which means calling .unify().boxed() after every or() call and all filters needs to call into_response() manually to convert to a Response.
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
I wish to make a route / filter that is enabled based on command line argument.
However, I find it is kind of cumbersome to have a filter optionally enabled.
I can currently find 3 solutions:
However, this requires coercing filter to the same exact type, which means calling
.unify().boxed()
after everyor()
call and all filters needs to callinto_response()
manually to convert to aResponse
.reject()
when this filter is not needed.However, this still requires me to make a custom reject filter that returns a
Extract = Response
.with_extra_feature
at each requestI would like to avoid this option as it is only determined by a factor that does not change after the program starts.
Describe the solution you'd like
A clear and concise description of what you want to happen.
If we make
Option<F> where F: Filter
implement Filter, whereNone
always reject.Then the above can be simplified to:
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
or_maybe
Implements a method like
or
, but accepts anOption<F>
whereNone
ignores the filter (rejects?).Either<L, R>
Similar to
futures::future::Either
, but accepts 2 filters instead.Additional context
Add any other context or screenshots about the feature request here.
N/A
The text was updated successfully, but these errors were encountered: