`tower_http::trace::{ResponseBody, ResponseFuture}` should default their generic parameters

[lilyball]

Bug Report

Version

tower-http v0.2.4

Description

tower_http::trace::{Trace, TraceLayer} both default most of their generic parameters. This is nice when I have to write out the actual type, such as when I return my middleware from a function and can't just infer the type.

Unfortunately, ResponseBody and ResponseFuture do not have defaults for their equivalent generic parameters. This means if I need to write out those types, I need to include all the types that I'm not writing for Trace or TraceLayer.

What I would expect is if I can write Trace<S, M> then I should also be able to write ResponseBody<ResBody, M::ClassifyEos> and ResponseFuture<S::Future, M::Classifier> instead of ResponseBody<ResBody, M::ClassifyEos, DefaultOnBodyChunk, DefaultOnEos, DefaultOnFailure> and ResponseFuture<S::Future, M::Classifier, DefaultOnResponse, DefaultOnBodyChunk, DefaultOnEos, DefaultOnFailure>.

It might also be nice to add type aliases in tower_http::trace like type HttpMakeClassifier = SharedClassifier<ServerErrorsAsFailures> and type GrpcMakeClassifier = SharedClassifier<GrpcErrorsAsFailures> (the two types used in the new_for_http() and new_for_grpc() methods) to make those easier to write out as well, and so I don't have to leave the trace module to write out my trace layer type.

[davidpdrsn]

Good idea!

[SharksT]

There is anyway currently to have TraceLayer together with CORS?

[davidpdrsn]

No. You need to write out the full types. I'd recommend writing things such that you don't have to do that.

[SharksT]

Do you have any public example of that?

[davidpdrsn]

Nope don't think so. You're welcome to open a discussion/question in you have a specific problem.