> Since our framework is deployed on several different CFML servlets -- > their implementation to get at the original http request wrapper differs > a bit (three different vendors). We'll probably stick to use the poor > man's encoding using a modified unicode representation of ";" in the > end. Another solution is to write a filter and use the getRequestURI() > and replace the bad path info in the request with the full length version.
>You could implement a Filter that wraps the request for these servlets. >The wrapped request would override the getPathInfo method and perform >the reverse-engineering of the path info you describe above. Yeah, the problem is the CFML engines run on a multitude of containers (not just Tomcat) and I'm not a contributor to any of the open source engines at the moment. >This would allow you to "patch" your servlets all at once without >actually modifying their code, and without going through the backflips >of an alternate URI encoding. One engine is proprietary engine by Adobe -- it's been like pulling teeth to get them to look into the issue. I doubt they will change their engine to fix this defect. Another engine Open BlueDragon ships with an SES Url Filter. It doesn't suffer the same truncation problem as the Adobe engine because it's doing what you suggested by bypassing the path info tomcat provides and parses throught the request.getRequestURI() itself and builds the correct path info and sets that to request. I'm unsure about the behaviour of the open source Railo engine because we just haven't had the time to verify it on that specific engine as such. I suspect that it suffers from the ";" truncation problem. >You could also log a bug and see what happens. As Bill points out, >nobody has been motivated to fix this issue. If you log a bug and get >some feedback, perhaps you could fix it yourself and submit a patch (if >you're motivated). Or, maybe some other kind soul will submit a patch >for it. Since you are motivated to have it work for your application, >you are a good candidate to fix it :) Yeah, I'll submit a bug report and see what happens -- I'll definitely submit a patch if I can find an elegant solution to it. i'm pretty unfamiliar with the Tomcat code base itself. Someone did mention about having to recombine stuff post path resolution -- I'm not sure exactly what was mention since I'm unfamiliar with the internals of Tomcat. Thanks for you help, Peter -- View this message in context: http://www.nabble.com/request.getPathInfo%28%29-gets-truncated-when-%22-%22-is-present-tp24633051p24653695.html Sent from the Tomcat - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
