Apache2/Tomcat5 Proxy/Rewrite issue

Hi,

since we started with OPS, we have been using Apache2 and then
proxy/rewrite to Tomcat5.
We have always wanted the URL the user sees to be a "normal" one,
without reference to platform/technology/application that was running
the site.
This has always worked great in the Eclipse environment.
When our first site went live, since we had no other webapps running
and no time left for further exploration, we installed our application
as ROOT.

Having learnt a lot about building OPS sites from that first site, we
started the next site from scratch.
We needed to put an interim version live in a hurry, and since we
hadn't started refactoring the original site to the new code, we needed
to install this as something other than ROOT.

The problems we faced might have been been because of some deficiency
in our proxy/rewrite setup, some Tomcat5 installation issue we have no
experience of, or a disconnect in OPS thinking, or ?.
(See below for our config)
We found that whenever OPS wanted to rewrite a URL, it would add in the
application name.
URLs we created, such as menus on the page, worked fine.
But references to images and css, even though they would be served
directly by Apache2, had the application name.
So instead of
http://domain.com/images/log.jpg
we got
http://domain.com/app/images/log.jpg
If we took the references we generated out of the xhtml namespace, then
they worked fine (came out as we wanted).
Of course, we couldn't do the same for the XForms references.
(Since we only had one simple form, we reimplemented it as an old HTML
form and connected it to the cgi we'd always used).

The (one) inference is that OPS is doing its rewriting in relation to
the Tomcat URL, rather than the Apache URL, even though the latter is
available (through the request processor as /request/server-name).

Does anyone have any ideas on how to get this all working properly (as
we want ;-).

Thanks & regards
Colin

 From our httpd.conf:
ProxyRequests Off
ProxyPassReverse / http://localhost:8080/ops/
ProxyPreserveHost On
ProxyErrorOverride On

RewriteEngine On
RewriteRule "^/(.*)\.(css)$" "$0" [L]
RewriteRule "^/(.*)\.(png|gif|ico|jpg)$" "$0" [L]
RewriteRule "^/(.*)" "http://localhost:8080/ops/$1" [P,L]




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Happy New Year!

This is a follow up on my message last month regarding the problems of
serving multiple sites from a single instance of OPS using Apache2 to
front Tomcat5.

More testing has produced a more workable environment, leaving two
issues I hope can be addressed.

My original httpd.conf started with
> ProxyPassReverse / http://localhost:8080/ops/
 From my reading of the Apache2 doc, this was needed so that Tomcat
would know the original targeted domain name.
That doesn't appear to be true, since things have only improved since I
removed it.

There are two OPS specific/operational directories that all OPS-based
sites need to be able to reach: ops and config.
By trapping these before doing my own redirects, OPS specific css and
js can be served from their normal places, and site-specific css and js
can be served from where each individual site stores that site's files.
For example
RewriteRule "^/config/(.*)" http://localhost:8080/ops/config/$1 [P,L]
RewriteRule "^/(.*)\.(css|js)$" "$0" [L]

When you start doing this, it immediately becomes obvious that giving
your webapp the name ops is too (potentially) confusing, so I have
since changed that.

If we cannot deal with the rewrite on the way out though, all this
detail on the way has no value.
I see in the doc that it does say that the epilogue will rewrite URLs
using the context, and that's what we are seeing, and while that can be
considered "correct", I would suggest it is not always "appropriate",
that it needs to take into account the wider 'context' (if present)
(apache, ...).

I have another site going into production next week, so this is urgent
for me.
Happily I have found a workaround, so a "real" answer in OPS is less
pressing.
Before all other rewrites, I just capture the misdirected requests and
correct them
RewriteRule "myapp/(.*)" "/$1"

This leaves one matter which I think is urgent, and seems easy to fix.
Obviously each site we are working on has its own set of images, and
since they are being transitioned from static sites, they are in the
same location everyone uses (/images) and is not a problem since we
have apache handle them.
OPS also has images.
For /config/theme this has been handled in what I would describe as an
appropriate manner, in that there is a sub-directory
/config/theme/images
But there is also an /images directory, which is used by files in /ops
(not sure if anything else).
It would seem to me that this would be improved by being moved to be
/ops/images
In that way, all my rewrite trapping would then work for jpg just as
well as css, as well as being more consistent, clearer packaging, etc.
I've done a quick grep and it seems there just around ten places in the
code where this will need to be changed.
Hope you agree it would be a useful enhancement.
Currently everything in the OPS /images is being not found (maybe this
isn't a problem ;-)

Thanks & regards
Colin

This is an abbreviated version of an httpd.conf illustrating what I now
have working

ProxyRequests Off
ProxyPreserveHost On

RewriteEngine On
RewriteRule "myapp/(.*)" "/$1"
RewriteRule "^/ops/(.*)" http://localhost:8080/myapp/ops/$1 [P,L]
RewriteRule "^/config/(.*)" http://localhost:8080/myapp/config/$1 [P,L]
RewriteRule "^/(.*)\.(css|js)$" "$0" [L]
RewriteRule "^/(.*)\.(png|gif|ico)$" "$0" [L]
RewriteRule "^/(.*)\.(jpg|jpeg)$" "$0" [L]
RewriteRule "^/(.*)" "http://localhost:8080/myapp/$1" [P,L]




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Colin O'Brien wrote:

 > If we cannot deal with the rewrite on the way out though, all this
 > detail on the way has no value.
 > I see in the doc that it does say that the epilogue will rewrite URLs
 > using the context, and that's what we are seeing, and while that can be
 > considered "correct", I would suggest it is not always "appropriate",
 > that it needs to take into account the wider 'context' (if present)
 > (apache, ...).

That's correct. The URL rewriting in fact sandboxes you into the
current Servlet context. However, if you put an f:url-norewrite="true"
attribute on your links, the URLs you write should not be rewritten.

 > Obviously each site we are working on has its own set of images, and
 > since they are being transitioned from static sites, they are in the
 > same location everyone uses (/images) and is not a problem since we have
 > apache handle them.
 > OPS also has images.
 > For /config/theme this has been handled in what I would describe as an
 > appropriate manner, in that there is a sub-directory /config/theme/images
 > But there is also an /images directory, which is used by files in /ops
 > (not sure if anything else).
 > It would seem to me that this would be improved by being moved to be
 > /ops/images
 > In that way, all my rewrite trapping would then work for jpg just as
 > well as css, as well as being more consistent, clearer packaging, etc.
 > I've done a quick grep and it seems there just around ten places in the
 > code where this will need to be changed.
 > Hope you agree it would be a useful enhancement.
 > Currently everything in the OPS /images is being not found (maybe this
 > isn't a problem ;-)

Currently, I find usages for these images in:

o examples (should not be a problem for you)
   most images

o the examples portal (should not be a problem for you):
   /images/new-window.gif

o some doc (should not be a problem for you):
   /images/remove.png
   /images/xforms-powered-86x31.png
   /images/ops30.png

o the theme (easily changed if necessary)
   /images/error-large.gif
   /images/loading.gif
   /images/error.gif (legacy)

o xforms-to-xhtml.xsl (legacy, should not be a problem for you)
   /images/showCalendar.gif
   /images/help-small.gif

o error page (easily changed if necessary)
   /images/plus.gif

o xforms.css (easily changed if necessary)

Probably that the images should be better located. I can clearly see a
few categories:

o images used by the examples
   -> maybe under /examples/images

o images used by the XForms engine's default theme
   -> maybe under /config/theme/images/xforms

o the doc already has its own images, which could be moved
   -> /examples/doc/pages/images or /examples/doc/images

I enter a bug to track this:

http://forge.objectweb.org/tracker/index.php?func=detail&aid=304626&group_id=168&atid=350207

-Erik




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws