Ok I am trying what you said. The original error as Tom suggested in application was http://www.spinics.net/lists/apache-users/msg95596.html its not possible to configure the application to generate absolute URLs. I just mentioned the above thread if you want to know what exactly I am trying.
On Wed, Jul 14, 2010 at 7:35 AM, Tapas Mishra wrote:
tl;dr
I’m not interested in wading through thousands of line of your logs looking for something of note. You will need to reduce your report to some specific request, and show log entries relating to just that request.
Tom
please forgive me if this is the wrong place for this question, or if this has been discussed elsewhere. i searched most of the night and morning, and then started pouring through the source code, and i’m pretty sure i’ve isolated the “issue” but need some advice as to where to go.
we have been using apache 1.3 as a caching reverse proxy in front of mod_perl backend servers for several years, and it has worked flawlessly. we recently took the leap to upgrade to 2.2, and everything is working generally well, but we are having some issues with on-disk caching using mod_disk_cache.
for each request, we determine which backend server to proxy off to based on various complex criteria, using mod_rewite. but our setup can be generalized as follows: we send “human” traffic to one set of machines and “bot” traffic to another. the content returned for each is a little different, mostly based on things like not including image-heavy widgets and links to pages or section of the site that require user login.
with apache 1.3, this worked swimmingly, as the key for the on-disk cache seemed to be generated based on the proxy target url, as opposed to the canonical request url.
$ sudo grep -rF -m1 ‘/stories/201007010002.html’ . ./R/U/dsvSj2WzpWj5Do8S0Lcw:X-URL: http://crawler:8082/stories/201007010002.html ./x/h/EiBz@6Q5ZMJcpUnUqnAg:X-URL: http://backend:8081/stories/201007010002.html
with the move to apache 2.2, it appears, based on the behavior we are seeing, as well as the comments in cache_storage.c, that the default key generation method is based on the canonical request url, taken before the translate name hook runs. the end result is that, based on our setup, we end up with “practical key collisions”, although there is not technically a collision. so in the above example, humans might see the cached version of the page as generated for bot consumption, or vice-versa.
looking at the cache key generation methods, and where they are called from, i could not see any way that i could, through the apache configuration, change this behavior. so is there a directive or module that i’m overlooking, or is there even a “simple” patch that i could apply that would get us back to the key generation behavior of 1.3, or something similar?
thanks in advance.
Ohh I see.Actually I have also noticed this thing and was wondering if there is any way to do so. I will forward this message to the right people as I am not the developer of sakai.
On Thu, Jul 8, 2010 at 10:52 AM, Tapas Mishra wrote:
Your application is generating URLs like this:
GET /library/skin/default/portal.css GET /portal/styles/portalstyles.css GET /library/js/jquery.js
mod_proxy does not rewrite HTML, only a few specific headers, so your application must generate the correct URLs, eg /’sakai/styles/portalstyles.css’. Configure your application correctly.
Cheers
Tom
I have a working instance of sakai on one of our clusters.Sakai can be read here http://confluence.sakaiproject.org/display/DOC/Install+Guide+-+Binary+Install+(2.7)
We would like the user to be able to reach it via Apache Reverse proxy
ProxyPass /sakai http://192.1681.5:9090/portal ProxyPassReverse /sakai http://192.1681.5:9090/portal
But when any one tries to reach the page from internet http://mydomain.com/sakai they are not able to reach the CSS,Java scripts ,images correctly.
which should not happen and be taken care by the reverse proxy
the request is not getting the correct response here are the apache headers for the problem
From a client browser on internet
following headers were recieved
where as on LAN while accessing via IP:9080/portal the following headers were recieved http://pastebin.com/0BaEViH4
If any one can find any problem here let me know. I am right now searching for the problem in the headers.
Did you configure Tomcat to return the proxy proxyName and proxyPort?
The doc is here: http://tomcat.apache.org/tomcat-5.5-doc/proxy-howto.html
I’m not *actually* sure if relative path redirects would be supported, I always concatenate the scheme +”:” + serverName +”:”+port when doing redirects.
Gabriel
2010/6/16 Jan Fröhlich :
Hi Gabriel,
thanks for your quick response. Maybe I have to add some information so you can pbb. help me.
My app server is a tomcat 5.5 configured with just a http/Port 80 connector. The server is reachable from local network with its hostname. The reverse proxy is configured to an external address (different from hostname) using https. So I guess configuring the tomcat to use the external names for host / port would lead to problems with requests from local network.
Reverse Proxy configuration looks like that: ProxyPass /myApp http://serverHostname/myApp ProxyPassReverse /myApp http://serverHostname/myApp
Thanks again!
Jan
Make sure your app server is correctly configured to return the font-end proxy values when you call: -request.getServerName() -request.getServerPort()
Gabriel
2010/6/16 Jan Fröhlich :
Hi all,
after (nearly) finishing a struts2 project with struts 2.1.8.1 we have an odd issue testing the application behind an apache reverse proxy server.
In web.xml is “index.jsp” as welcome page defined. Index.jsp contains just a (please don’t ask if its necessary).
Home.action is secured by an LoginInterceptor that checks for a valid session in some backend system and redirects to login.action if the session is invalid.
After a successful login through a login form, the home.action is called.
In our test environment everything works fine with http. When we test it with https behind an apache reverse proxy every redirect described above leads to a switch in the protocol from https to http. Once the home.action is loaded, and the following calls are made with jQuery, everything works fine.
There is no absolute link in the application, we are always using relative paths.
Any help appreciated!!
Regards,
Jan