- Upgraded from Prime 3.0 to 3.2 and having issues with using curl and php curl when trying to pull information using the filtering. For example:-
- >curl -k "https://<user>:<pass>@<server>/webacs/api/v3/data/AccessPointDetails?macAddress=\"<mac>\""
- Curl error: Empty reply from serverurl
- The same result with using php curl.
- When using curl to obtain a list of devices without using a filter, it returns the results fine.
- On PI 3.0 this was working fine so not sure what changed in 3.2. Tested a sample Ruby script and that works fine so even more weird!
It seems there's been a regression here.Opened CSCvf16644 to track this issue
You can replace the \" escaped double-quotes with percent encoded double quotes. For example macAddress=%2200:11:22:33:44:55%22
We've concluded our investigation into this issue; unfortunately, we'll be closing the bug (indicating that we believe the reported issue is valid but will go unfixed).
In PI, we use Apache Tomcat to handle our HTTP traffic. In resolving CVE-2016-6816, Tomcat's behavior was changed to strictly enforce RFC 3986's allowed URL characters. So, whenever an unencoded character is present in a URL, Tomcat will now immediately return an HTTP 400 response. This seems to occur before filters are invoked, which means we don't have that avenue to alter Tomcat's behavior. Furthermore, we can't identify any Tomcat configuration we'd be able to specify to workaround this particular issue.
So because this change in behavior was made to mitigate a vulnerability, and because the workaround is easy to implement, and for the reasons above, we're closing this bug. We will be making documentation changes to clarify things, but the behavior will go on as it is in 3.2.
We've updated the 3.2 Reference Guide and Tutorial in DevNet regarding this. We've also incorporated these documentation changes in the first maintenance release of 3.2.
With regards to the encoding of special characters in the URL. it's better to force the API clients to use correct encoding.