Open damooo opened 2 years ago
I agree that the current situation is untenable. The current name of Uri
suggests that the struct can be all sorts of things that URIs and URLs can be, when in reality it's simply "the thing you use to specify an HTTP request target" nothing more. I personally think a lot of confusion can be saved by renaming Uri
as stated above, despite the fact that this is a breaking change. Certainly would have saved me quite a bit.
Unfortunately, 1.0 was released without addressing this. So renaming Uri
is out of the question for the foreseeable future, I assume. I still think that some of this confusion can be avoided by improving the docs.
I just stumbled over this issue, as I was confused by the whole situation again. It doesn't help that the docs mention the fragment in the syntax breakdown diagram, but nowhere else. Neither does the fact that parsing an URI with fragment succeeds but silently discards the fragment part.
As this crate stands for correctness, it is imperative to fix misleading terminology that is used through out the request-target handling documentation.
HttpRequestTarget
instead ofUri
, as it really handles only request target forms, not identity scheme in any way. This may be difficult, noting it is a breaking change. Can alias and deprecate though.Uri
struct, There is extensive use ofabsolute-uri
/relative-uri
dichotomy to show that, forabsolute-uri
it hasport
,scheme
, etc, and forrelative-uri
it won't. This is grossly misleading. As this crate is not handling identifiers in the first place, there is no such thing asabsolute-uri
/relative-uri
dichotomy. It is instead dichotomy ofabsolute-form
/origin-form
of request target. i.e, request-target inabsolute-form
encodes port, scheme etc, and that inorigin-form
doesn't, as they have to be runtime-resolved. That's also the reason the mis-termedrelative-uri
s starts with a/
, as they are not really identifiers, relative/absolute, butorigin-form
resource targets.The second point of fixing documentation may not be breaking change, and possible i hope.
We can see many misunderstandings due to this misleading. for example
127, As These are not identifiers, but representation of request-target values, there is no uri, and thus no fragments in first place.
465 Same mis-issue of using request-target representation to represent identifiers
469 They even mention other uri-schemes in issue discription, and also quotes uri-standard. Same mis-issue.
396 ,
url
crate is for identifiers, where as this one only deals with request-targets.379 same issue. This crate doesn't handles uris in first place. only request targets.
342
311
323
421
306
176
110
so on, so forth. For amount of confusion, ad misleading it creates, It may be helpful to fix at least terminology in docs, and fix
Uri
name for struct before1.0
see https://github.com/solid/specification/issues/368