• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

URI does not allow spaces in tomcat 7.0.68 - how to bypass that

 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

We have been using tomcat for.. well forever.. currently we use tomcat 7.0.27. Yes it is old.. but its a very complex product using tomcat as the app server, and running in 14 countries an upgrade is NOT simple and can take years to implement.

I would like to upgrade to tomcat 7.0.68 BUT we need to be able to use URI's with spaces in them when using redirects. This works like a charm in 7.0.27 but in 7.0.68 we get the

thrown in


does anyone have a clue on how to allow spaces in the URI ?
I can off course correct the issue in the org.apache.catalina.connector.Response.sendRedirect source code, but I am hoping there is a way to instruct tomcat to NOT reject spaces?? Some config parameter maybe?

All ideas are most welcome :-)
 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What is the URI in question?

Spaces are generally not encouraged in URIs, but there are ways to deal with them.
 
Hen Rat
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Holloway wrote:What is the URI in question?

Spaces are generally not encouraged in URIs, but there are ways to deal with them.



there is no specific URI.. it is constructed dynamically to call a MapServer (renders GIS map data) which is in fact a CGI based application.
But as an example it could contain "xxx= 1 and 2"
the mapserver component does not support URL decoding so it does not work if I encode it like: "xxx=%201%20and%202"
 
Hen Rat
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In other words: encoding it with either + or %20 is unfortunately not usable
 
Tim Holloway
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Hen Rat
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.



you are correct.. but i cannot do that as the CGI script must receive the query string decoded (MapServer interprets % as placeholders for parameters and therefore canno understand %20 as part of a query string :-(..
and as we issue a http redirect from a servlet (a Spring Controller in this case) I cannot circumvent that Tomcat parses the query string AND demands it to be encoded.

So I was hoping to find a way to disable this parsing that Tomcat does in 7.0.68 but NOT in 7.0.27.. for instance there are options like:


I was hoping that I might have missed some property setting that would disable the new introduced forced parsing of all URLs/query strings and so on..
 
Tim Holloway
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Hen Rat
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.



I agree.. the MapServer is wrong.. its bad.. BUT I have to use it.. there is no way around that fact.
Just to be clear: I care A LOT about security..have doen so for more than 15 years. Our product is scanned at least twice a year by the worlds most advanced security agencies.
And I take pride in the fact that it never failed any of those tests.

My problem is still: how can I use a non-encoded query string in tomcat 7.0.68 like I do now in 7.0.27

If I can't, then we will not upgrade. Or I will find a way to intercept the call to the CGI script and decode it there.. if possible.. somehow.
I KNOW the request format is at fault, but I need to find a pragmatic solution without investing years of development and several million dollars in developing a version not using MapServer as the GIS renderer.
 
Tim Holloway
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Hen Rat
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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




thanks for the idea.. I will try a valve and see if that fixes it..

if not, a apache proxy could be a work around.. unfortunately a huge task to implement at our customers.. but it might be the only way.

Thank you for your time!
 
Hen Rat
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
and to be more precise.. I can easily encode/fix the querystrings... but the mapserver cannot use them.
So to be fair: it is a MapServer issue more than a Tomcat issue.. but the "problem" was introduced by the Tomcat 7.0.68.
 
Hen Rat
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
SOLVED

turned out to be a missing

in the <tomcat_home>/conf/context.xml file


so encoding just spaces and % characters turned out to be enough IF one remembers to add the privileged attribute

Thanks for the input. Sometimes one can stare at code forever and not see the obvious.. even if I KNEW that off course I needed to set the privileged attribute.. stupid me

Hope this helps someone else som day
 
reply
    Bookmark Topic Watch Topic
  • New Topic