View App Proxy IBIS-Q Parameter with <= characters Pass Through

[garth]

The view app's query proxy pass through proxy controller can NOT be used for IBIS-Q parameters which contain "<=" type characters. These get encoded/escaped by the query result controller but the call never reaches the query proxy pass through controller as either the Apache proxy/Tomcat/or Spring's request dispatcher can't handle these in the URL? Don't know for sure since log doesn't show entering the app. The result is always can't locate requested resource/file.

At one point thought that it be a character encoding issue IBISQ needs UTF-8 and View deals with ISO-8801. However, tested with both UTF-8, ISO8801, and nothing and all produce the same result. Tried surrounding the entry with " and with ' both without success. Tried removing the "=" sign and simply having =9<x<14. This also did NOT work. Even the first =10<bmomage does NOT work (nor if quoted). The only way to get it to go through is to remove the "<" characters or escape them with "&lt;". However, escaping causes everything past the first "&" to be lost as it views this as the next parameter . Also tried reversing the logic e.g. using >= as well as =>. Of course the straight encoding was also unsuccessfully tried (%3c%3d). Even tried "%26lt;=" which produces the same result as &lt;.

This is not a problem for the view app when it is deployed on the Utah server and has a firewall hole so the controller is able to communicate to the CGI directly (and sends UTF-8). It is only an issue for developers testing queries which go through the production view query proxy to reach the Utah SAS server.

Another Option: Put the problematic parameters in the .def file. Example: f data_where 10<=bmomage<=14

If a character encoding issue then this could be problem for other agencies who deploy into different character enviros.

2-2-08: Turned on a bunch of filter and NetLib? logging and put on DC server. DC Server did NOT have an issue with <= at all. Tried different configs and worked!!! This environment is XP-Pro, Apache, Tomcat 5.5. So apparently, the issue is with Utah's environment. Either the Linux Apache proxy server or the Tomcat on Linux (which shouldn't be the case as Tomcat is pure Java).

[garth]

12/20 ish, added encoding filter for posted data and for the query proxy pass through rewrote all parameters with a new encoding. Added properties so these can be changed to fit various needs e.g. one needs ISO8859 and another wants full UTF-8.

Tested and it made NO difference. Requests are not getting to the app. Either Tomcat is catching or the spring request dispatcher is!?

[anonymous]

Milestone View system deployment for wide testing deleted