http::Error is completely opaque

[dekellum]

The http::Error type, the higher level error returned from various http builders, is missing a commonly advocated/desired facility for programmatic access. I suspect this was just an oversight of its late addition, not the intent. Currently http::Error is as opaque as any StringError, so for example when building a response via response::Builder, the only way to distinguish between InvalidHeaderName and InvalidStatusCode is by testing Error::to_string, Display or Debug format string.

The only other workaround is to not use the builder types, where that is possible, as for this example using Response::from_parts, etc., but we prefer using the builders for ergonomics.

[carllerche]

Hmm... the goal is to avoid tight coupling between error types.

It could be exposed via a http::Error::downcast_ref::<T>() -> Option<&T> type of fn. Thoughts @seanmonstar?

[dekellum]

Yep, I understand that something like this was necessary for the builders, to return a single error type on the final "building" call. Its just missing some way to test for certain causes, which are already exported, lower level error types, e.g. InvalidHeaderName.

For implementation I think #303 has some advantage, but I'll comment on that there.