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
From the naming I gathered that the intended use case for normalize was that uris that are semantically equivalent should get a canonical form. Some examples where this is currently not the case:
Is this sort of out of scope for this library? Should this be added?
Also, from my understanding of rfc3986, but this might be wrong, if I want to use a reserved character as part of the data I need to percent-encode it. For example, let's say I want to use / in my data, the request for an endpoint of /api/{data} could look for example something like "http://foobar.com/api/some%2Fdata". normalize would then confound the following two uris.
Normalize does not currently handle dot segments or default ports, it only deals with percent encoding at the moment. We do have the algorithm for dot segment resolution implemented as part or uri/join, I think it could make sense to add that to normalize.
alysbrooks
changed the title
Intended use case for normalize
Expand normalize to handle special delimiters in path segment and (possibly) handle normalization of dot segments
Jul 17, 2023
From the naming I gathered that the intended use case for
normalize
was that uris that are semantically equivalent should get a canonical form. Some examples where this is currently not the case:Path segments:
Scheme based normalization (the following are urls are equivalent)
See here.
Is this sort of out of scope for this library? Should this be added?
Also, from my understanding of rfc3986, but this might be wrong, if I want to use a reserved character as part of the data I need to percent-encode it. For example, let's say I want to use
/
in my data, the request for an endpoint of/api/{data}
could look for example something like"http://foobar.com/api/some%2Fdata"
.normalize
would then confound the following two uris.So my question is, shouldn't only unreserved characters be decoded as part of the normalization?
The text was updated successfully, but these errors were encountered: