struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Max Cooper <...@maxcooper.com>
Subject Re: forcing relative urls from struts instead of the absolute urls!
Date Wed, 04 Jan 2006 21:57:28 GMT
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message