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.
Hi
I am sorry. This problem is on the application side of our team and they asked me to look into possible Apache issues.
Basically, they have submitted a case with Oracle, and they responded with the following: ****** Oracle Support – May 20, 2010 10:21:59 AM GMT-04:00 Comments
On 25 Jun 2010, at 13:09, tuyen.nguyen@teradyne.com wrote:
On the basis of what you’ve told us, nothing. But that’s because you’ve told us nothing.
TIAS. RTFM. If necessary, ask about specific problems as and when you encounter them.
We are getting intermittent proxy timeout erros due to using reverse proxy running Primavera web services using Apache 2.0.59 as the web server. We sent the issue to Primavera support and they have indicated that this is an Apache bug 37770. I would like to understand the extent of Apache bug 37770 and is it present in this version of Apache 2.0.59 and is it fixed in 2.0.63? Are there any configuration changes we can make which would reduce or resolve the frequency of these proxy timeouts?
I don’t know why our original application was installed on 2.0 in 2007, however if we were to upgrade the latest of Apache 2.2, what differences can we expect to configure to get the same compatibility as 2.0?
Thank you for whatever help you can give.
Tuyen.
On Wed, Jun 23, 2010 at 5:43 AM, CORISCO NIETO, ALBERTO wrote:
…
What version of the Archetype plugin are you using? It sounds like http://jira.codehaus.org/browse/ARCHETYPE-202 .