Return-Path: Delivered-To: apmail-httpd-users-archive@www.apache.org Received: (qmail 59972 invoked from network); 18 Nov 2008 12:41:57 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 18 Nov 2008 12:41:57 -0000 Received: (qmail 53044 invoked by uid 500); 18 Nov 2008 12:41:53 -0000 Delivered-To: apmail-httpd-users-archive@httpd.apache.org Received: (qmail 53030 invoked by uid 500); 18 Nov 2008 12:41:53 -0000 Mailing-List: contact users-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: users@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@httpd.apache.org Received: (qmail 53019 invoked by uid 99); 18 Nov 2008 12:41:53 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 18 Nov 2008 04:41:53 -0800 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,NORMAL_HTTP_TO_IP,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of bocalinda@gmail.com designates 72.14.220.155 as permitted sender) Received: from [72.14.220.155] (HELO fg-out-1718.google.com) (72.14.220.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 18 Nov 2008 12:40:31 +0000 Received: by fg-out-1718.google.com with SMTP id 16so2620262fgg.40 for ; Tue, 18 Nov 2008 04:41:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=81IpORLUL4yIWwIwFOSUjv3km4UEnHPptPzFkrehLLI=; b=gWW3nLNhL1mTiPh2CAqe1DOsUt6sG0BzKXWCgVBCziifoa92QHgEWjlMMszQNZfv4l bRD/6UiK6cUu8/wsQs2g/lqv2w9LjEWpgTiBDwY1xnjGfkVd1haAayAqLqHV4ReJBusd HGbd5sLsvwQrFCWOdqhSCJwAJMZMiv3Nbpqk8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=KVh9Oc0gOi4fflWadlTbUHyncBPS5c0IeGK5zXISwQjmz0Dg8lky0rOC0NxnGtq9ts PFAWv5C+ciwK1iWy/j1dhavhsKBf9S55JLq6Mwdhiu0l/GhhtvP0MprKFvAGAwvobwjU J+FuujNyUoP1+kZ3A5u5DIifUvINWBM8a0Gcw= Received: by 10.187.225.12 with SMTP id c12mr652518far.9.1227012064348; Tue, 18 Nov 2008 04:41:04 -0800 (PST) Received: by 10.187.224.8 with HTTP; Tue, 18 Nov 2008 04:41:04 -0800 (PST) Message-ID: Date: Tue, 18 Nov 2008 13:41:04 +0100 From: Bocalinda To: users@httpd.apache.org In-Reply-To: <4922B163.20607@ice-sa.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_23631_2701412.1227012064341" References: <4921C1B3.9070309@ice-sa.com> <4921F78A.10707@ice-sa.com> <49220008.3050500@ice-sa.com> <37A57134-7916-48EE-A6BF-6E5E41AA7947@livecurrent.com> <4922B163.20607@ice-sa.com> X-Virus-Checked: Checked by ClamAV on apache.org Subject: Re: [users@httpd] Rewrite relative image paths in a reversed proxy setup ------=_Part_23631_2701412.1227012064341 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Andr=E9. Yes, for now just those two applications are involved. However, it might be that new applications will be added. Thanks a bunch for the tip though! 2008/11/18 Andr=E9 Warnier > Hi. > Now in your case, it was just the 2 URLs "/SEDO" and "/SEDO-NEW" that > needed to be rewritten and cause a re-direct, no ? > If so, you could use the following RewriteRule, which should not have the= se > inconvenients : > > RewriteRule ^/(SEDO(-NEW)?)$ $1/index.jsp [R=3D301,L] > > > > Bocalinda wrote: > >> Hey guys, >> >> There is one problem with this solution. >> RewriteRule ^/([^/]+)$ $1/ [R=3D301,L] >> >> http://172.18.0.1/SEDO/test.html will also be added a trailing slash. >> I changed the regular expression to NOT add a trailing slash if there is= a >> dot in the string. >> RewriteRule ^/([^/\.]+)$ $1/ [R=3D301,L] >> >> Let's hope they won't be using directory names with dots in over here :) >> >> >> 2008/11/18 Bocalinda >> >> Hi Andr=E9 and Dan, >>> >>> Thanks a lot, this solved my problem! >>> Just one question Dan. >>> >>> Apache will (in the default configuration) redirect /SEDO to /SEDO/ (= if >>>> >>> 'SEDO' is a directory). If you're proxying back, Apache won't >know tha= t >>> obviously, but you can use a rewrite rule to simulate this: >>> >>> Sorry for my ignorance, but could you explain why that is obvious? >>> I'm just getting started with the proxy stuff and now and then I still >>> get >>> confused. >>> >>> Thanks again, it's greatly appreciated! >>> >>> 2008/11/18 Dan Udey >>> >>> You could also, in order to keep the URLs pretty and SEO and whatnot, >>> just >>> >>>> add an extra / on the end. >>>> >>>> Apache will (in the default configuration) redirect /SEDO to /SEDO/ (= if >>>> 'SEDO' is a directory). If you're proxying back, Apache won't know tha= t >>>> obviously, but you can use a rewrite rule to simulate this: >>>> >>>> RewriteRule ^/([^/]+)$ $1/ [R=3D301,L] >>>> >>>> So / will be redirected to // automatically, and >>>> then >>>> browsers will know to look for //image.gif - in this case >>>> is any string without a slash anywhere in it >>>> >>>> If your URLs only have alphanumeric characters in them, you can pretty >>>> up >>>> the rule like so: >>>> >>>> RewriteRule /([a-zA-Z0-9]+)$ $1/ [R=3D301,L] >>>> >>>> Which is still not pretty, but is somewhat less ugly. Either way, it >>>> fixes >>>> the problem in question. >>>> >>>> >>>> On 17-Nov-08, at 3:36 PM, Andr=E9 Warnier wrote: >>>> >>>> Andr=E9 Warnier wrote: >>>> >>>>> Bocalinda wrote: >>>>>> >>>>>> Yes, that would be /SEDO/index.jsp >>>>>>> >>>>>>> Ok, now a simple test : >>>>>> When, instead of requesting >>>>>> http://yourserversip/SEDO >>>>>> if you request in your browser >>>>>> http://yourserversip/SEDO/index.jsp >>>>>> then your relative image links are working, right ? >>>>>> (provided the images are really there) >>>>>> >>>>>> Now replying to my own previous post, because I want to go to bed a= nd >>>>> so >>>>> you would not have to wait for the conclusion : >>>>> >>>>> My reasoning is that the browser does what it does, and what it does = is >>>>> right : if it sees the link in a page that it >>>>> received >>>>> when it requested >>>>> http://server/SEDO >>>>> the it will request >>>>> http://server/image.gif >>>>> for the image. >>>>> So far, ok for the browser, but that does not resolve your problem. >>>>> >>>>> To resolve your problem, the browser must known that when it requeste= d >>>>> http://server/SEDO >>>>> what it really got was >>>>> http://server/SEDO/index.jsp >>>>> so that it can interpret the link as the requ= est >>>>> URL >>>>> http://server/SEDO/image.gif >>>>> >>>>> The way to tell the browser that, would be that when it requests >>>>> http://server/SEDO >>>>> it receives a response from the server saying "no no, that's not ther= e, >>>>> but it's here instead" : >>>>> http://server/SEDO/index.jsp >>>>> That is called a re-direct, or a 301/302 response. >>>>> The browser, when it receives this, will (automatically and >>>>> transparently) request again the resource, but this time as >>>>> http://server/SEDO/index.jsp >>>>> and following that, it will correctly interpret >>>>> as >>>>> http://server/SEDO/image.gif >>>>> (or http://server/SEDO_NEW/image.gif as the case may be) >>>>> which URLs will be proxied to Tomcat and thus properly load-balanced. >>>>> CQFD >>>>> >>>>> So now, the trick consists in having your server, upon request of >>>>> http://server/SEDO >>>>> to send back a re-direct to >>>>> http://server/SEDO/index.jsp >>>>> and that is probably a matter for mod_rewrite, or maybe just a >>>>> configuration directive in Apache. >>>>> (See the Redirect* directives) >>>>> Note : in the URL to "redirect to", make sure that you specify it wit= h >>>>> a >>>>> leading "http://server", because otherwise Apache may get smart and d= o >>>>> an internal re-direct, which would not be known by your browser, and >>>>> thus >>>>> defeat the above logic. >>>>> >>>>> Hope this helps, as they say. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> 2008/11/17 Andr=E9 Warnier >>>>>>> >>>>>>> Bocalinda wrote: >>>>>>> >>>>>>>> Hi Andr=E9. >>>>>>>> >>>>>>>>> I'm glad we managed to understand eachother :) >>>>>>>>> >>>>>>>>> >>>>>>>>> Sorry, maybe I did not use the correct example before, but that i= s >>>>>>>>> wrong. >>>>>>>>> >>>>>>>>> If you original request is >>>>>>>>>> http://172,18.0.1/SEDO >>>>>>>>>> and from there, your browser receives an html page (wherever it >>>>>>>>>> came >>>>>>>>>> from), >>>>>>>>>> and that html page contains a link , the= n >>>>>>>>>> the >>>>>>>>>> browser >>>>>>>>>> will request >>>>>>>>>> http://172,18.0.1/SEDO/image.gif >>>>>>>>>> >>>>>>>>>> wait a minute.. maybe it won't. Because it would remove the >>>>>>>>>> "SEDO", >>>>>>>>>> for >>>>>>>>>> being the last path component, and replace it by "image.gif". >>>>>>>>>> Now I think I get it. >>>>>>>>>> The browser would have to know that it is not really getting >>>>>>>>>> "SEDO", >>>>>>>>>> but >>>>>>>>>> /SEDO/something. >>>>>>>>>> Hmmm. >>>>>>>>>> >>>>>>>>>> I guess that the only way to make this work (if you cannot chang= e >>>>>>>>>> the >>>>>>>>>> >>>>>>>>>> links in the pages), would be to force a re-direct to the real >>>>>>>>>> thing, >>>>>>>>>> when >>>>>>>>>> the browser requests "SEDO". >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> That's what I tried before. But the thing is that I don't know >>>>>>>>>> >>>>>>>>> where to >>>>>>>>> redirect to, because: >>>>>>>>> >>>>>>>>> a. I don't know whether image.gif belongs to SEDO or SEDO-NEW >>>>>>>>> b. I don't want to hardcode a Tomcat URL, because that server cou= ld >>>>>>>>> be >>>>>>>>> down. >>>>>>>>> >>>>>>>>> What is the resource that the browser really obtains when it >>>>>>>>> requests >>>>>>>>> >>>>>>>>> http://172,18.0.1/SEDO ? >>>>>>>>>> (this must be something on your Tomcats) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The resource in the browser remains http://172.18.0.1/SEDO all >>>>>>>>>> the >>>>>>>>>> >>>>>>>>> time. >>>>>>>>> While I see the following in my apache error logs: >>>>>>>>> >>>>>>>>> No such file or folder /htdocs/image.gif (More or less, I'm not >>>>>>>>> behind >>>>>>>>> that >>>>>>>>> computer right now). >>>>>>>>> >>>>>>>>> I'm puzzled. >>>>>>>>> I think it may have to do with ProxyPassReverse not being set >>>>>>>>> properly. >>>>>>>>> >>>>>>>>> >>>>>>>>> Wait. I repeat : >>>>>>>>> >>>>>>>>> What is the resource that the browser *really* obtains when it >>>>>>>>>> requests >>>>>>>>>> http://172.18.0.1/SEDO ? >>>>>>>>>> (this must be something on your Tomcats) >>>>>>>>>> >>>>>>>>>> Let's forget for the time being about "image.gif". It is the >>>>>>>>> step >>>>>>>>> >>>>>>>> before >>>>>>>> that, which interests me. >>>>>>>> When the browser requests "http://172.18.0.1/SEDO", it first gets >>>>>>>> an >>>>>>>> html >>>>>>>> page. That page is probably defined as being your "Welcome >>>>>>>> document" >>>>>>>> for >>>>>>>> that directory in Tomcat. What is that document ? >>>>>>>> Put another way, which equivalent URL could be used to get the sam= e >>>>>>>> page >>>>>>>> from Tomcat ? >>>>>>>> (Maybe "index.jsp" or something ?) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------------------= --- >>>>>>>> The official User-To-User support forum of the Apache HTTP Server >>>>>>>> Project. >>>>>>>> See for more info. >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org >>>>>>>> " from the digest: users-digest-unsubscribe@httpd.apache.org >>>>>>>> For additional commands, e-mail: users-help@httpd.apache.org >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----------------------------------------------------------------= ---- >>>>>>> >>>>>> The official User-To-User support forum of the Apache HTTP Server >>>>>> Project. >>>>>> See for more info. >>>>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org >>>>>> " from the digest: users-digest-unsubscribe@httpd.apache.org >>>>>> For additional commands, e-mail: users-help@httpd.apache.org >>>>>> >>>>>> >>>>> --------------------------------------------------------------------- >>>>> The official User-To-User support forum of the Apache HTTP Server >>>>> Project. >>>>> See for more info. >>>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org >>>>> " from the digest: users-digest-unsubscribe@httpd.apache.org >>>>> For additional commands, e-mail: users-help@httpd.apache.org >>>>> >>>>> >>>>> --------------------------------------------------------------------= - >>>> The official User-To-User support forum of the Apache HTTP Server >>>> Project. >>>> See for more info. >>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org >>>> " from the digest: users-digest-unsubscribe@httpd.apache.org >>>> For additional commands, e-mail: users-help@httpd.apache.org >>>> >>>> >>>> >> > > --------------------------------------------------------------------- > The official User-To-User support forum of the Apache HTTP Server Project= . > See for more info. > To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org > " from the digest: users-digest-unsubscribe@httpd.apache.org > For additional commands, e-mail: users-help@httpd.apache.org > > ------=_Part_23631_2701412.1227012064341 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Andr=E9.

Yes, for now just those two applications are involved.However, it might be that new applications will be added.
Thanks a bun= ch for the tip though!

2008/11/18 Andr=E9= Warnier <aw@ice-sa.c= om>
Hi.
Now in your case, it was just the 2 URLs "/SEDO" and "/SEDO-= NEW" that needed to be rewritten and cause a re-direct, no ?
If so, you could use the following RewriteRule, which should not have these= inconvenients :

RewriteRule ^/(SEDO(-NEW)?)$ $1/index.jsp [R=3D301,L]



Bocalinda wrote:
Hey guys,

There is one problem with this solution.
RewriteRule  ^/([^/]+)$ $1/ [R=3D301,L]

http://172.1= 8.0.1/SEDO/test.html will also be added a trailing slash.
I changed the regular expression to NOT add a trailing slash if there is a<= br> dot in the string.
RewriteRule  ^/([^/\.]+)$ $1/ [R=3D301,L]

Let's hope they won't be using directory names with dots in over he= re :)


2008/11/18 Bocalinda <bocalinda@gmail.com>

Hi Andr=E9 and Dan,

Thanks a lot, this solved my problem!
Just one question Dan.

Apache will (in the default configuration) redirect /SEDO to /SEDO/  (= if
'SEDO' is a directory). If you're proxying back, Apache won'= ;t >know that
obviously, but you can use a rewrite rule to simulate this:

Sorry for my ignorance, but could you explain why that is obvious?
I'm just getting started with the proxy stuff and now and then I still = get
confused.

Thanks again, it's greatly appreciated!

2008/11/18 Dan Udey <dan@communicate.com>

You could also, in order to keep the URLs pretty and SEO and whatnot, just<= br>
add an extra / on the end.

Apache will (in the default configuration) redirect /SEDO to /SEDO/  (= if
'SEDO' is a directory). If you're proxying back, Apache won'= ;t know that
obviously, but you can use a rewrite rule to simulate this:

      RewriteRule ^/([^/]+)$ $1/ [R=3D301,L]

So /<anything> will be redirected to /<anything>/ automatically= , and then
browsers will know to look for /<anything>/image.gif - in this case <anything> is any string without a slash anywhere in it

If your URLs only have alphanumeric characters in them, you can pretty up the rule like so:

      RewriteRule /([a-zA-Z0-9]+)$ $1/ [R=3D301,L]

Which is still not pretty, but is somewhat less ugly. Either way, it fixes<= br> the problem in question.


On 17-Nov-08, at 3:36 PM, Andr=E9 Warnier wrote:

 Andr=E9 Warnier wrote:
Bocalinda wrote:

Yes, that would be /SEDO/index.jsp

Ok, now a simple test :
When, instead of requesting
http://yourserversi= p/SEDO
if you request in your browser
http://yo= urserversip/SEDO/index.jsp
then your relative image links are working, right ?
(provided the images are really there)

Now replying to my own previous post, because I want to go to bed and so you would not have to wait for the conclusion :

My reasoning is that the browser does what it does, and what it does is
right : if it sees the link <img src=3D"image.gif"> in a pa= ge that it received
when it requested
http://server/SEDO
the it will request
http://server/image.g= if
for the image.
So far, ok for the browser, but that does not resolve your problem.

To resolve your problem, the browser must known that when it requested
http://server/SEDO
what it really got was
http://server/SE= DO/index.jsp
so that it can interpret the link <img src=3D"image.gif"> a= s the request
URL
http://server/SE= DO/image.gif

The way to tell the browser that, would be that when it requests
http://server/SEDO
it receives a response from the server saying "no no, that's not t= here,
but it's here instead" :
http://server/SE= DO/index.jsp
That is called a re-direct, or a 301/302 response.
The browser, when it receives this, will (automatically and
transparently) request again the resource, but this time as
http://server/SE= DO/index.jsp
and following that, it will correctly interpret <img src=3D"image.g= if"> as
http://server/SE= DO/image.gif
(or http://s= erver/SEDO_NEW/image.gif as the case may be)
which URLs will be proxied to Tomcat and thus properly load-balanced.
CQFD

So now, the trick consists in having your server, upon request of
http://server/SEDO
to send back a re-direct to
http://server/SE= DO/index.jsp
and that is probably a matter for mod_rewrite, or maybe just a
configuration directive in Apache.
(See the Redirect* directives)
Note : in the URL to "redirect to", make sure that you specify it= with a
leading "http://server= ", because otherwise Apache may get smart and do
an internal re-direct, which would not be known by your browser, and thus defeat the above logic.

Hope this helps, as they say.







2008/11/17 Andr=E9 Warnier <aw@ice-sa.com>

 Bocalinda wrote:
 Hi Andr=E9.
I'm glad we managed to understand eachother :)


Sorry, maybe I did not use the correct example before, but that is
wrong.

If you original request is
http://172,18.0.1/SEDO
and from there, your browser receives an html page (wherever it came
from),
and that html page contains a link <img href=3D"image.gif">= , then the
browser
will request
http://172,18.0.1/SEDO/image.g= if

wait a minute.. maybe it won't. Because it would remove the "SEDO&= quot;,
for
being the last path component, and replace it by "image.gif".
Now I think I get it.
The browser would have to know that it is not really getting "SEDO&quo= t;,
but
/SEDO/something.
Hmmm.

I guess that the only way to make this work (if you cannot change
the
<img>
links in the pages), would be to force a re-direct to the real
thing,
when
the browser requests "SEDO".


 That's what I tried before. But the thing is that I don't kno= w
where to
redirect to, because:

a. I don't know whether image.gif belongs to SEDO or SEDO-NEW
b. I don't want to hardcode a Tomcat URL, because that server could
be
down.

What is the resource that the browser really obtains when it requests

http://172,18.0.1/SEDO ?
(this must be something on your Tomcats)


 The resource in the browser remains http://172.18.0.1/SEDO all the
time.
While I see the following in my apache error logs:

No such file or folder /htdocs/image.gif  (More or less, I'm not behind
that
computer right now).

I'm puzzled.
I think it may have to do with ProxyPassReverse not being set
properly.


Wait. I repeat :

What is the resource that the browser *really* obtains when it
requests
http://172.18.0.1/SEDO= ?
(this must be something on your Tomcats)

Let's forget for the time being about "image.gif".  It i= s the step
before
that, which interests me.
When the browser requests "http://172.18.0.1/SEDO", it first gets an
html
page.  That page is probably defined as being your "Welcome docum= ent"
for
that directory in Tomcat.  What is that document ?
Put another way, which equivalent URL could be used to get the same
page
from Tomcat ?
(Maybe "index.jsp" or something ?)


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server
Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
"   from the digest: users-digest-unsubscribe@httpd.apache.or= g
For additional commands, e-mail: users-help@httpd.apache.org



 ---------------------------------------------------------------------=
The official User-To-User support forum of the Apache HTTP Server
Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
 "   from the digest: users-digest-unsubscribe@httpd.apa= che.org
For additional commands, e-mail: users-help@httpd.apache.org


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server
Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
 "   from the digest: users-digest-unsubscribe@httpd.apa= che.org
For additional commands, e-mail: users-help@httpd.apache.org


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.<= br> See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
 "   from the digest: users-digest-unsubscribe@httpd.apa= che.org
For additional commands, e-mail: users-help@httpd.apache.org





---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.<= br> See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
 "   from the digest: users-digest-unsubscribe@httpd.ap= ache.org
For additional commands, e-mail: users-help@httpd.apache.org


------=_Part_23631_2701412.1227012064341--