Hi Benoit_Mortgat,
This is still in our backlog of potential features to consider.
There are some challenges with implementing this. Consider the input URI string has both encoded and unencoded components.
1.Regarding the first suggestion, only percent encoding the non ascii characters will not be sufficient. What if the non ascii string also has characters like '%'. We will have to percent encode it.
The new API will have to make certain assumptions like if the string has a '%' character followed by two hexadecimal digits, assume that it is already encoded. If not, go ahead and percent encode the '%' character too.
Which implies, if your input string is something like: "http://localhost/encodedstr1%C5%9Fend/encodedstr2%xyend" the new API will end up not encoding the first path component "encodedstr1%C5%9Fend" and encoding the second one "encodedstr2%xyend" while the first component could have been a valid unencoded string.
2.When the URI components have reserved characters: It is difficult to break the URI into its components. For instance, if the unencoded string has the path delimiter character '/' in it, we cannot tell if the parser should treat this as the path delimiter or as a character that needs to be encoded.
What do you think of the above two cases, can your application also run into such inputs?
Since this is not a straightline scenario, but an extended feature, we may not be able to get to it by the next release.
I will definitely keep you posted if we make any progress here.
Thanks
Kavya
This is still in our backlog of potential features to consider.
There are some challenges with implementing this. Consider the input URI string has both encoded and unencoded components.
1.Regarding the first suggestion, only percent encoding the non ascii characters will not be sufficient. What if the non ascii string also has characters like '%'. We will have to percent encode it.
The new API will have to make certain assumptions like if the string has a '%' character followed by two hexadecimal digits, assume that it is already encoded. If not, go ahead and percent encode the '%' character too.
Which implies, if your input string is something like: "http://localhost/encodedstr1%C5%9Fend/encodedstr2%xyend" the new API will end up not encoding the first path component "encodedstr1%C5%9Fend" and encoding the second one "encodedstr2%xyend" while the first component could have been a valid unencoded string.
2.When the URI components have reserved characters: It is difficult to break the URI into its components. For instance, if the unencoded string has the path delimiter character '/' in it, we cannot tell if the parser should treat this as the path delimiter or as a character that needs to be encoded.
What do you think of the above two cases, can your application also run into such inputs?
Since this is not a straightline scenario, but an extended feature, we may not be able to get to it by the next release.
I will definitely keep you posted if we make any progress here.
Thanks
Kavya