On Tue, 2006-01-03 at 16:51 -0500, Michael P. Soulier wrote: > On 13/12/05 Max Cooper did say: > > > It sounds like your main challenge is that you have requests to a web > > server that look like http://web.domain.com/foo/bar/me mapped to an app > > deployed on an app server that you might access directly as > > http://app.domain.com/me. The app will make site-root relative URLs > > like /me/foo.html, and the browser will them make a request to the web > > server like http://web.domain.com/me/foo.html which is not what you > > want. > > That is correct. > > > What is stopping you from deploying the app with a "/foo/bar/me" > > context, so that it matches the "public" context on the web server? This > > is almost certainly the easiest solution if you can do it. > > In this case, http://web.domain.com/foo is a prefix for a lot of UI > elements that are pluggable for separate applications. That would mean > that if /foo became a web application in tomcat, it would be much more > difficult for applications to plug-in to it. If each application > delivered a .war file, as a separate web application, that would be far > easier to maintain in the long run than requiring all developers to > coexist in one large web app under tomcat.
I am not following why you can't make the "context path" (whether it is a webapp or not) the same on your app server as it is on the web server, e.g. http://web.com/foo --proxy--> http://app.com/foo, rather that http://web.com/foo --proxy--> http://app.com/something/else. This really would solve all of your problems -- perhaps it is worth further consideration, even if you have to change some paths to make it work. Note that I think you can deploy completely separate webapps to the following seemingly-nested paths, if this is the problem: /foo /foo/bar /foo/bar/baz Or how about setup another virtual host on tomcat, with the app (or whatever it is) deployed with a context path that matches the path on the public web server. > > Alternately, perhaps there is some proxy configuration magic that would > > work. To be robust, you'd probably need to use a connector (e.g. mod_jk) > > rather than just using a "dumb" proxy to forward requests, because I > > think the app server really needs to know the desired context path in > > order to render the pages with the proper URLs. (The alternative of > > filtering the response stream after-the-fact in hopes of converting all > > URLs is a lousy design for many reasons and not an approach I would > > recommend.) > > I'm currently using ProxyPass in apache, but if this can be done with > mod_jk, then I'll focus on that. Do you know it's possible with AJP? I was hoping that I would see config items to address this, but I didn't see any when reviewing the docs. I guess it doesn't do it, at least not alone. Maybe it could be combined with mod_rewrite in some novel way to solve this problem, but I don't know how to do it. I do like using mod_jk (and similar for components other app servers) since they handle things (e.g. redirect URLs) that can be a pain to setup in a proxy and/or pain to work around with app code. Basically, they give you a solid base to build on, without a bunch of surprising proxy-related gotchas to work around in the app code. Be a little more specific about your situation -- I think that might help someone recognize a problem they had and offer you a solution. You can obviously obscure the particulars while still communicating the structure of your problem in sufficient detail. So far, I don't really get what your situation is beyond "path on web server doesn't match context path on app server". -Max --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
