Open hawkw opened 1 year ago
I'm happy to put together a quick PR for this, but I figured it was worth opening an issue first.
Why not let users downcast it? If http will also 1.0 I don't see the issue in that? Otherwise, I agree with what you said.
Why not let users downcast it? If http will also 1.0 I don't see the issue in that? Otherwise, I agree with what you said.
When http
1.0 is released, we should probably make it available as a source/downcast target. In the meantime, it would still be better to at least display it in fmt::Display
.
Is your feature request related to a problem? Please describe.
When an invalid URI is parsed by the
http
crate, it returns anInvalidUri
error. Whenhyper
encounters one of these errors, it converts it into ahyper::Error
type with an error kind that indicates that an invalid URI was encountered. Thehttp::uri::InvalidUri
type contains additional information describing what part of the URI was invalid, which is included in the error'sfmt::Display
output: https://github.com/hyperium/http/blob/c1f309e0c3695f8e14e1b54c738681783d4c7b9e/src/uri/mod.rs#L1063-L1079Unfrortunately, when
hyper
converts these errors into itshyper::Error
type, the additional information is discarded: https://github.com/hyperium/hyper/blob/75aac9f47fe0246016e6133cd3cfa35b63c8904e/src/error.rs#L489-L499The error that's returned to the application will format as just "invalid URI", which is not particularly descriptive. Being able to surface more information about why a URI was invalid would be useful, particularly in applications where URIs are input by the user.
Describe the solution you'd like
It would be nice if
hyper
preserved the description of what part of the URI was invalid. I think we should probably change theParse::Uri
variant inhyper::error
to contain anhttp::uri::InvalidUri
, so that we can format the additional error information in thefmt::Display
impl forhyper::Error
.Since we don't want to expose types from other crates in
hyper
's public API, for stability reasons, we probably shouldn't allow the user to access thehttp::uri::InvalidUri
error in thehyper::Error
source chain, or allow downcasting the error to it.Describe alternatives you've considered
http::uri::InvalidUri
as asource
ofhyper::Error
. This might be conceptually the "right thing", but it would expose a type from an external crate inhyper
's public API, which is undesirable ashttp
is not yet 1.0.