The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Tim Holloway wrote:What is the URI in question?
Spaces are generally not encouraged in URIs, but there are ways to deal with them.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Tim Holloway wrote:It doesn't sound like you are dealing with a URI. It sounds more like a query string. I would assume that you are entering the query in as a web URL request and having a servlet or JSP in Tomcat forward the actual query on to the mapserver.
In a case like this, the usual practice would be to URL-encode the request and have the server action decode it, if necessary.
In other words, assuming something like: "http://www.mymap.com:8080/mapper/search?q=xx=1+and+2", and if the "q" parameter wasn't pre-decoded (which I think it should be, actually), then use the java.net.URLDecoder class to decode q.
If you use the getQueryString() method, you will have to manually decode the text, but since the recommended URL syntax for query strings is a set of name/value pairs, a simple getParameter() on the HttpURLRequest should be sufficient.
You might also want to look at how Google handles stuff like that.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Tim Holloway wrote:The URL encoding for "%" is "%%" or "%25". So a query in the form: "lat = % and long = %" would properly be encoded as:
lat=+%%+and+long+=+%%
The fact that Tomcat has become more rigorous about URL syntax should not be disregarded or hacked around. The original request format is at fault and should be repaired.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Tim Holloway wrote:I worked with MapServer about 7 years ago and had no trouble with it.
However, if you are unable to repair the URIs, then you have 2 choices, I think:
1. Try implementing a Tomcat Valve to allow for the bad syntax.
2. Bypass Tomcat altogether. Since you say you are forwarding the request, consider using something more tolerant as a proxy.
A malformed URI isn't just a possible security issue. It can cause things to break without warning. Case in point; Tomcat 7.0.68. Someday MapServer itself may close the loophole.
Incidentally, I think this may be similar to what you are doing: http://lists.osgeo.org/pipermail/mapserver-users/2003-October/046355.html