Jorge Olguin (super carnicerias hernandez sa de cv) asked a question.
created a REST service (it took me 4 minutes to code the method and 2 minutes to publish the resource) to expose product information for the mobile app team, so they can build on top of it. However, we discovered that one product has an ID containing the string "S/H", and this causes issues when trying to send it to another endpoint that expects a URL like:
https://.../rest/s/getProductbyID/pechuga s/h
This request fails due to the forward slash in the product ID.
Other products with spaces in their IDs (registered over 20 years ago) can be queried successfully using URL encoding (e.g., %20 for spaces).
The problem is that "S/H" cannot be safely substituted with "S%2FH" in the URL path, as the slash is still interpreted as a path delimiter.
Would converting this into a POST request, with the product ID passed in the request body, be a viable solution?
Based on our findings, I would consider this a bug at this point (or perhaps a hidden feature based on some RFC?), but in any case, there is a workaround if you are using .NET classes (HttpWebRequest, etc.). You can either modify the prowin.exe.config file or rewrite the method mentioned in the link to the source code in Progress and call it before REST.
Source: https://mikehadlow.blogspot.com/2011/08/how-to-stop-systemuri-un-escaping.html
Tomcat, by default, disallows percent-encoded slash values in the path/URL.
You can try to not do so by changing the value of the ALOW_ENCODED_SLASH to true in the conf/jvm.properties file (for PASOE at least).
> Would converting this into a POST request, with the product ID passed in the request body, be a viable solution?
Yes. This might be a better approach. If you're using the GET method you could try to pass it as a query parameter, although I think that's subject to the same rule.