I am having issues dealing with special characters in a REST URI. The reason we need to deal with special characters is because the URI can reference an ID and that ID may contain a special character, something like:
http://myServer/v1/myResource/123<abc>
The solution that we currently have is not the easiest for consumers of the API in that special characters need to be double encoded. So, for the above, the URI would look like:
http://myServer/v1/myResource/123%253Cabc%253E
I am hoping we can do something better and have two questions.
(1) Why isn't single encoding the URI enough. Specifically, if I change the URI to the following:
http://myServer/v1/myResource/123%3Cabc%3E
Then I get an error along the lines:
A potentially dangerous Request.Path value was detected from the client (<)
This is happening, in part, because something is decoding the URI somewhat prematurely. Interestingly, this does work OK when I try the URI on the same machine as the REST web server. That is, the "premature" URI decoding only happens when REST request is coming from a remote machine.
(2) requestPathInvalidCharacters
By setting requestPathInvalidCharacters to empty string, most of the characters only need to be single encoded. This is a reasonable solution for us, though I haven't been able to determine if this opens us up to any security concerns. From what I can tell, it does not since this web server will only be used for REST. However, I am not certain.
Does setting requestPathInvalidCharacters open any security issues when only using REST API and, if so, can you provide an example where security might be an issue?
Thanks in advance, Eric