You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Bocalinda <bo...@gmail.com> on 2008/11/17 13:38:21 UTC
[users@httpd] Rewrite relative image paths in a reversed proxy setup
Hi all.
I have an Apache server that takes care of load balancing four Tomcat
servers, using mod_proxy.
The four Tomcat servers are setup in two clusters:
cluster1: 2 Tomcats 5.5.7
cluster2: 2 Tomcats 5.5.27
Now, I have depending on the application that is being requested, the
request should be send to cluster1 or cluster2.
I have this setup working using the <Location> tag.
<Proxy balancer://mycluster1>
BalancerMember ajp://172.18.0.39:8009 route=vdebian1
BalancerMember ajp://172.18.0.40:8009 route=vdebian2
</Proxy>
<Proxy balancer://mycluster2>
BalancerMember ajp://172.18.0.78:8009 route=vdebian3
BalancerMember ajp://172.18.0.84:8009 route=vdebian4
</Proxy>
<Location /SEDO>
ProxyPass balancer://mycluster1 stickysession=JSESSIONID
ProxyPassReverse /
</Location>
<Location /SEDO-NEW>
ProxyPass balancer://mycluster2 stickysession=JSESSIONID
ProxyPassReverse /
</Location>
This works perfectly as I expected. However, the problem I have is that some
images or links on my webapp are specified relatively.
For example <img href="image.gif">, which results in errors because the
image cannot be found on the root of my server, which is logical.
So, I thought I'd use the following:
<LocationMatch ^(.*\.gif)$>
ProxyPassMatch balancer://mycluster1/$1
</LocationMatch>
However, the problem is that I do not know to which application the image
belongs, thus I don't know either to which cluster I should proxy the
request.
So I thought using mod_proxy_html to rewrite the URLs in the HTML files:
<Location /SEDO>
ProxyPass balancer://mycluster1 stickysession=JSESSIONID
ProxyPassReverse /
SetOutputFilter proxy-html
ProxyHTMLURLMap (.*\.gif) http://172.18.0.39:8080/$1 Rie
</Location>
This works, however, what I do not like is that I map the URLs to a
hardcoded server. What if the Tomcat instance is down? Then my images won't
be loaded.
As far as I tried, it is also impossible to specify a cluster path as URL.
Thus, my question folks, how can I solve this? I've been thinking about
using Vhosts, but I don't know if that would be the right solution. Maybe
there is something easier, such as altering a HTTP reponse header in order
to know which webapp requested the image.
Any help will be kindly appreciated.
Re: [users@httpd] Rewrite relative image paths in a reversed proxy setup
Posted by Bocalinda <bo...@gmail.com>.
Sounds perfect.
I don't mind having to add a new entry each time I have a new application,
since I need to do the same
in order to make the application load balance.
I wonder if there would be a way to have a default load balancing route.. :)
2008/11/18 André Warnier <aw...@ice-sa.com>
> Well then, not to overdo it, but you can use either this
>
> RewriteRule ^/(SEDO-NEW|SEDO|ABCD|XYZ)?)$ $1/index.jsp [R=301,L]
> (and keep on adding alternatives as need be)
> or this
> RewriteRule ^/(SEDO)$ $1/index.jsp [R=301,L]
> RewriteRule ^/(SEDO-NEW)$ $1/index.jsp [R=301,L]
> RewriteRule ^/(ABCD)$ $1/index.jsp [R=301,L]
> RewriteRule ^/(XYZ)$ $1/index.jsp [R=301,L]
> ...
> since each rule is marked "last", the first one to match "wins".
> It's a tiny bit less efficient, but maybe more readable and flexible.
>
>
> Bocalinda wrote:
>
>> Hi André.
>>
>> 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é Warnier <aw...@ice-sa.com>
>>
>> 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=301,L]
>>>
>>>
>>>
>>> Bocalinda wrote:
>>>
>>> Hey guys,
>>>>
>>>> There is one problem with this solution.
>>>> RewriteRule ^/([^/]+)$ $1/ [R=301,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=301,L]
>>>>
>>>> Let's hope they won't be using directory names with dots in over here :)
>>>>
>>>>
>>>> 2008/11/18 Bocalinda <bo...@gmail.com>
>>>>
>>>> Hi André 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 <da...@communicate.com>
>>>>>
>>>>> 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
>>>>>> that
>>>>>> obviously, but you can use a rewrite rule to simulate this:
>>>>>>
>>>>>> RewriteRule ^/([^/]+)$ $1/ [R=301,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=301,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é Warnier wrote:
>>>>>>
>>>>>> André 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
>>>>>>>> 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="image.gif"> 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
>>>>>>> requested
>>>>>>> http://server/SEDO
>>>>>>> what it really got was
>>>>>>> http://server/SEDO/index.jsp
>>>>>>> so that it can interpret the link <img src="image.gif"> as the
>>>>>>> request
>>>>>>> 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
>>>>>>> there,
>>>>>>> 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 <img src="image.gif">
>>>>>>> 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
>>>>>>> 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é Warnier <aw...@ice-sa.com>
>>>>>>>
>>>>>>>> Bocalinda wrote:
>>>>>>>>>
>>>>>>>>> Hi André.
>>>>>>>>>>
>>>>>>>>>> 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="image.gif">, then
>>>>>>>>>>>> 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
>>>>>>>>>>>> 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 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
>>>>>>>>>>> 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 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
>>>>>>>>>> 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.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.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 <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.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.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 <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.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.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
Re: [users@httpd] Rewrite relative image paths in a reversed proxy
setup
Posted by André Warnier <aw...@ice-sa.com>.
Well then, not to overdo it, but you can use either this
RewriteRule ^/(SEDO-NEW|SEDO|ABCD|XYZ)?)$ $1/index.jsp [R=301,L]
(and keep on adding alternatives as need be)
or this
RewriteRule ^/(SEDO)$ $1/index.jsp [R=301,L]
RewriteRule ^/(SEDO-NEW)$ $1/index.jsp [R=301,L]
RewriteRule ^/(ABCD)$ $1/index.jsp [R=301,L]
RewriteRule ^/(XYZ)$ $1/index.jsp [R=301,L]
...
since each rule is marked "last", the first one to match "wins".
It's a tiny bit less efficient, but maybe more readable and flexible.
Bocalinda wrote:
> Hi André.
>
> 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é Warnier <aw...@ice-sa.com>
>
>> 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=301,L]
>>
>>
>>
>> Bocalinda wrote:
>>
>>> Hey guys,
>>>
>>> There is one problem with this solution.
>>> RewriteRule ^/([^/]+)$ $1/ [R=301,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=301,L]
>>>
>>> Let's hope they won't be using directory names with dots in over here :)
>>>
>>>
>>> 2008/11/18 Bocalinda <bo...@gmail.com>
>>>
>>> Hi André 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 <da...@communicate.com>
>>>>
>>>> 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 that
>>>>> obviously, but you can use a rewrite rule to simulate this:
>>>>>
>>>>> RewriteRule ^/([^/]+)$ $1/ [R=301,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=301,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é Warnier wrote:
>>>>>
>>>>> André 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 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="image.gif"> 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 requested
>>>>>> http://server/SEDO
>>>>>> what it really got was
>>>>>> http://server/SEDO/index.jsp
>>>>>> so that it can interpret the link <img src="image.gif"> as the request
>>>>>> 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 there,
>>>>>> 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 <img src="image.gif">
>>>>>> 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 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é Warnier <aw...@ice-sa.com>
>>>>>>>> Bocalinda wrote:
>>>>>>>>
>>>>>>>>> Hi André.
>>>>>>>>>
>>>>>>>>>> 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="image.gif">, then
>>>>>>>>>>> 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 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 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 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 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 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.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.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 <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.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.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 <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.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.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Rewrite relative image paths in a reversed proxy setup
Posted by Bocalinda <bo...@gmail.com>.
Hi André.
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é Warnier <aw...@ice-sa.com>
> 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=301,L]
>
>
>
> Bocalinda wrote:
>
>> Hey guys,
>>
>> There is one problem with this solution.
>> RewriteRule ^/([^/]+)$ $1/ [R=301,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=301,L]
>>
>> Let's hope they won't be using directory names with dots in over here :)
>>
>>
>> 2008/11/18 Bocalinda <bo...@gmail.com>
>>
>> Hi André 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 <da...@communicate.com>
>>>
>>> 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 that
>>>> obviously, but you can use a rewrite rule to simulate this:
>>>>
>>>> RewriteRule ^/([^/]+)$ $1/ [R=301,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=301,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é Warnier wrote:
>>>>
>>>> André 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 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="image.gif"> 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 requested
>>>>> http://server/SEDO
>>>>> what it really got was
>>>>> http://server/SEDO/index.jsp
>>>>> so that it can interpret the link <img src="image.gif"> as the request
>>>>> 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 there,
>>>>> 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 <img src="image.gif">
>>>>> 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 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é Warnier <aw...@ice-sa.com>
>>>>>>>
>>>>>>> Bocalinda wrote:
>>>>>>>
>>>>>>>> Hi André.
>>>>>>>>
>>>>>>>>> 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="image.gif">, then
>>>>>>>>>> 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 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 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 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 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 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.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.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 <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.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.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 <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.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
Re: [users@httpd] Rewrite relative image paths in a reversed proxy
setup
Posted by André Warnier <aw...@ice-sa.com>.
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=301,L]
Bocalinda wrote:
> Hey guys,
>
> There is one problem with this solution.
> RewriteRule ^/([^/]+)$ $1/ [R=301,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=301,L]
>
> Let's hope they won't be using directory names with dots in over here :)
>
>
> 2008/11/18 Bocalinda <bo...@gmail.com>
>
>> Hi André 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 <da...@communicate.com>
>>
>> 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 that
>>> obviously, but you can use a rewrite rule to simulate this:
>>>
>>> RewriteRule ^/([^/]+)$ $1/ [R=301,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=301,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é Warnier wrote:
>>>
>>> André 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 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="image.gif"> 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 requested
>>>> http://server/SEDO
>>>> what it really got was
>>>> http://server/SEDO/index.jsp
>>>> so that it can interpret the link <img src="image.gif"> as the request
>>>> 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 there,
>>>> 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 <img src="image.gif"> 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 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é Warnier <aw...@ice-sa.com>
>>>>>>
>>>>>> Bocalinda wrote:
>>>>>>> Hi André.
>>>>>>>> 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="image.gif">, then 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 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 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 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 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 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.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.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 <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.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.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 <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.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Rewrite relative image paths in a reversed proxy setup
Posted by Bocalinda <bo...@gmail.com>.
Hey guys,
There is one problem with this solution.
RewriteRule ^/([^/]+)$ $1/ [R=301,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=301,L]
Let's hope they won't be using directory names with dots in over here :)
2008/11/18 Bocalinda <bo...@gmail.com>
> Hi André 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 <da...@communicate.com>
>
> 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 that
>> obviously, but you can use a rewrite rule to simulate this:
>>
>> RewriteRule ^/([^/]+)$ $1/ [R=301,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=301,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é Warnier wrote:
>>
>> André 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 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="image.gif"> 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 requested
>>> http://server/SEDO
>>> what it really got was
>>> http://server/SEDO/index.jsp
>>> so that it can interpret the link <img src="image.gif"> as the request
>>> 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 there,
>>> 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 <img src="image.gif"> 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 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é Warnier <aw...@ice-sa.com>
>>>>>
>>>>> Bocalinda wrote:
>>>>>>
>>>>>> Hi André.
>>>>>>> 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="image.gif">, then 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 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 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 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 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 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.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.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 <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.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.apache.org
>> For additional commands, e-mail: users-help@httpd.apache.org
>>
>>
>
Re: [users@httpd] Rewrite relative image paths in a reversed proxy setup
Posted by Bocalinda <bo...@gmail.com>.
Hi André 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 <da...@communicate.com>
> 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 that
> obviously, but you can use a rewrite rule to simulate this:
>
> RewriteRule ^/([^/]+)$ $1/ [R=301,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=301,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é Warnier wrote:
>
> André 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 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="image.gif"> 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 requested
>> http://server/SEDO
>> what it really got was
>> http://server/SEDO/index.jsp
>> so that it can interpret the link <img src="image.gif"> as the request 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 there,
>> 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 <img src="image.gif"> 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 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é Warnier <aw...@ice-sa.com>
>>>>
>>>> Bocalinda wrote:
>>>>>
>>>>> Hi André.
>>>>>> 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="image.gif">, then 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 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 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 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 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 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.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.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 <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.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.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
Re: [users@httpd] Rewrite relative image paths in a reversed proxy setup
Posted by Dan Udey <da...@communicate.com>.
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
that obviously, but you can use a rewrite rule to simulate this:
RewriteRule ^/([^/]+)$ $1/ [R=301,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=301,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é Warnier wrote:
> André 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
> 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="image.gif"> 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 requested
> http://server/SEDO
> what it really got was
> http://server/SEDO/index.jsp
> so that it can interpret the link <img src="image.gif"> as the
> request 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
> there, 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 <img
> src="image.gif"> 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
> 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é Warnier <aw...@ice-sa.com>
>>>
>>>> Bocalinda wrote:
>>>>
>>>>> Hi André.
>>>>> 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="image.gif">, then
>>>>>> 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
>>>>>> 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 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
>>>>> 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 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
>>>> 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.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.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 <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.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.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Rewrite relative image paths in a reversed proxy
setup
Posted by André Warnier <aw...@ice-sa.com>.
André 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 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="image.gif"> 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 requested
http://server/SEDO
what it really got was
http://server/SEDO/index.jsp
so that it can interpret the link <img src="image.gif"> as the request 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 there,
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 <img src="image.gif"> 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 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é Warnier <aw...@ice-sa.com>
>>
>>> Bocalinda wrote:
>>>
>>>> Hi André.
>>>> 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="image.gif">, then 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 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 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 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 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 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.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.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 <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.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Rewrite relative image paths in a reversed proxy
setup
Posted by André Warnier <aw...@ice-sa.com>.
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)
>
> 2008/11/17 André Warnier <aw...@ice-sa.com>
>
>> Bocalinda wrote:
>>
>>> Hi André.
>>> 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="image.gif">, then 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 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 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 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 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 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.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.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Rewrite relative image paths in a reversed proxy setup
Posted by Bocalinda <bo...@gmail.com>.
Yes, that would be /SEDO/index.jsp
2008/11/17 André Warnier <aw...@ice-sa.com>
> Bocalinda wrote:
>
>> Hi André.
>> 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="image.gif">, then 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 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 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 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 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 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.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
Re: [users@httpd] Rewrite relative image paths in a reversed proxy
setup
Posted by André Warnier <aw...@ice-sa.com>.
Bocalinda wrote:
> Hi André.
> 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="image.gif">, then 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 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 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 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 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 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.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Rewrite relative image paths in a reversed proxy setup
Posted by Bocalinda <bo...@gmail.com>.
Hi André.
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="image.gif">, then 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 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 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 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.
>
>
> ---------------------------------------------------------------------
> 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.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
Re: [users@httpd] Rewrite relative image paths in a reversed proxy
setup
Posted by André Warnier <aw...@ice-sa.com>.
Bocalinda wrote:
> Hi André.
>
>
>>> Applying what you explained above, this would mean that my images paths
>>> will
>>> be resolved as:
>>> http://172.18.0.1/SEDO/image.gif
>>>
>>> Which of course will not work.
>>>
>> Why "of course" ?
>> I may be thick, but I must admit I do not really understand your problem.
>>
> Sorry for the confusion, the above image.gif URL wasn't correct.
> If the image path is relative in the form of "image.gif" then the correct
> path would be:
> http://172,18.0.1/image.gif and this of course will not work. (see below)
>
>> What I mean is : if the page your browser sees contains a tag <img
>> href="image.gif">, the browser will resolve this according to the location
>> from which it got the page that contains that link.
>> That's how browsers work, and are supposed to work.
>> If you do not want this, then do not put relative links in the pages, put
>> absolute links.
>> Like <img href="/images/image.gif">.
>> The browser, mind you, will still resolve this according to the host from
>> which it got your page, but this time will look for
>> http://172.18.0.1/images/image.gif.
>>
>> But what do you want to happen, really ?
>> Where would you like the image to come from ?
>>
>
> Hmm, ok. Let me explain what I think is going wrong.
>
> I request http://172,18.0.1/SEDO.
> As you can see in my Apache configuration, the SEDO location requests will
> be proxied to Tomcat cluster1.
> Let's say that the request will be send to 172.18.0.39. Bear in mind that
> the URL in my browser won't change. That's the whole idea behind a reverse
> proxy. For the client it seems that Apache is serving my pages, while in
> reality it's one of my Tomcat servers in my cluster. Thus, my browser URL is
> still 172.18.0.1.
>
> Anyway, as you stated, any relative img paths will be resolved to
> http://172.18.0.1/image.gif.
> But (and this is where the problem is located), this URL will not be proxied
> to any of my Tomcat clusters, because the URL does not contain SEDO or
> SEDO-NEW
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="image.gif">, then
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 change the
<img> links in the pages), would be to force a re-direct to the real
thing, when the browser requests "SEDO".
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 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.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Rewrite relative image paths in a reversed proxy setup
Posted by Bocalinda <bo...@gmail.com>.
Hi André.
>> Applying what you explained above, this would mean that my images paths
>> will
>> be resolved as:
>> http://172.18.0.1/SEDO/image.gif
>>
>> Which of course will not work.
>>
> Why "of course" ?
> I may be thick, but I must admit I do not really understand your problem.
>
Sorry for the confusion, the above image.gif URL wasn't correct.
If the image path is relative in the form of "image.gif" then the correct
path would be:
http://172,18.0.1/image.gif and this of course will not work. (see below)
>
> What I mean is : if the page your browser sees contains a tag <img
> href="image.gif">, the browser will resolve this according to the location
> from which it got the page that contains that link.
> That's how browsers work, and are supposed to work.
> If you do not want this, then do not put relative links in the pages, put
> absolute links.
> Like <img href="/images/image.gif">.
> The browser, mind you, will still resolve this according to the host from
> which it got your page, but this time will look for
> http://172.18.0.1/images/image.gif.
>
> But what do you want to happen, really ?
> Where would you like the image to come from ?
>
Hmm, ok. Let me explain what I think is going wrong.
I request http://172,18.0.1/SEDO.
As you can see in my Apache configuration, the SEDO location requests will
be proxied to Tomcat cluster1.
Let's say that the request will be send to 172.18.0.39. Bear in mind that
the URL in my browser won't change. That's the whole idea behind a reverse
proxy. For the client it seems that Apache is serving my pages, while in
reality it's one of my Tomcat servers in my cluster. Thus, my browser URL is
still 172.18.0.1.
Anyway, as you stated, any relative img paths will be resolved to
http://172.18.0.1/image.gif.
But (and this is where the problem is located), this URL will not be proxied
to any of my Tomcat clusters, because the URL does not contain SEDO or
SEDO-NEW (which is how I detect to send a request to cluster1 or cluster2).
Thus, Apache will try to load the image from it's local htdocs folder, and
exactly..there is no such image there.
Please let me know if you understand my description.
Thanks in advance.
Re: [users@httpd] Rewrite relative image paths in a reversed proxy
setup
Posted by André Warnier <aw...@ice-sa.com>.
Bocalinda wrote:
> Maybe just a note before you go make all kinds of changes.
>
>> With an <img> tag like above, it is not so that the server will look in the
>> DocumentRoot.
>> You have to look at it the other way around.
>> The browser, when it sees this tag in the current page, is going to
>> "compose" a URL to retrieve it, on the base of :
>> - the URL at which it retrieved the current page (the one that contains the
>> <img> tag
>> - removing the last component (iow the name of the page itself)
>> - then substituting the "image.gif" part
>>
>> In other words, if the current page was retrieved at :
>> http://yourserver.com/SEDO/subdir/mypage.html
>> and that page contains the tag above, then the browser will retrieve the
>> image at
>> http://yourserver.com/SEDO/subdir/image.gif
>> The server has nothing to do with it, it just tries to deliver what is
>> requested by the browser.
>>
>
> Thank you very much for your time.
> That makes perfectly sense.
> Then I guess I need to add a few more bits of information.
> I'm accessing my Apache server through a virtual IP address (LinuxHA + LVS).
> Say 172.18.0.1.
> Thus I access my load balanced application through:
> http://172.18.0.1/SEDO
>
> Applying what you explained above, this would mean that my images paths will
> be resolved as:
> http://172.18.0.1/SEDO/image.gif
>
> Which of course will not work.
Why "of course" ?
I may be thick, but I must admit I do not really understand your problem.
> As you can see, the image requests should be load balanced as well.
And they will be, according to your previous configuration.
>
>
>> Now, for your static elements like images, you have two choices :
>> - either you let things go as above, these requests will be forwarded to
>> Tomcat, will be balanced, and it means your images should be at the
>> corresponding locations in your Tomcat's
>> - or you do something at the Apache level that will prevent these URLs to
>> be passed to Tomcat, and you serve them locally at the Apache level.
>> In other words you exclude links ending in ".gif", ".jpg", ".xxx" from the
>> proxying.
>>
>
>
> I'm afraid this won't be an option.
>
What I mean is : if the page your browser sees contains a tag <img
href="image.gif">, the browser will resolve this according to the
location from which it got the page that contains that link.
That's how browsers work, and are supposed to work.
If you do not want this, then do not put relative links in the pages,
put absolute links.
Like <img href="/images/image.gif">.
The browser, mind you, will still resolve this according to the host
from which it got your page, but this time will look for
http://172.18.0.1/images/image.gif.
But what do you want to happen, really ?
Where would you like the image to come from ?
---------------------------------------------------------------------
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.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Rewrite relative image paths in a reversed proxy setup
Posted by Bocalinda <bo...@gmail.com>.
Maybe just a note before you go make all kinds of changes.
> With an <img> tag like above, it is not so that the server will look in the
> DocumentRoot.
> You have to look at it the other way around.
> The browser, when it sees this tag in the current page, is going to
> "compose" a URL to retrieve it, on the base of :
> - the URL at which it retrieved the current page (the one that contains the
> <img> tag
> - removing the last component (iow the name of the page itself)
> - then substituting the "image.gif" part
>
> In other words, if the current page was retrieved at :
> http://yourserver.com/SEDO/subdir/mypage.html
> and that page contains the tag above, then the browser will retrieve the
> image at
> http://yourserver.com/SEDO/subdir/image.gif
> The server has nothing to do with it, it just tries to deliver what is
> requested by the browser.
>
Thank you very much for your time.
That makes perfectly sense.
Then I guess I need to add a few more bits of information.
I'm accessing my Apache server through a virtual IP address (LinuxHA + LVS).
Say 172.18.0.1.
Thus I access my load balanced application through:
http://172.18.0.1/SEDO
Applying what you explained above, this would mean that my images paths will
be resolved as:
http://172.18.0.1/SEDO/image.gif
Which of course will not work.
As you can see, the image requests should be load balanced as well.
> Now, for your static elements like images, you have two choices :
> - either you let things go as above, these requests will be forwarded to
> Tomcat, will be balanced, and it means your images should be at the
> corresponding locations in your Tomcat's
> - or you do something at the Apache level that will prevent these URLs to
> be passed to Tomcat, and you serve them locally at the Apache level.
> In other words you exclude links ending in ".gif", ".jpg", ".xxx" from the
> proxying.
>
I'm afraid this won't be an option.
Re: [users@httpd] Rewrite relative image paths in a reversed proxy
setup
Posted by André Warnier <aw...@ice-sa.com>.
Bocalinda wrote:
> This works perfectly as I expected. However, the problem I have is that some
> images or links on my webapp are specified relatively.
> For example <img href="image.gif">, which results in errors because the
> image cannot be found on the root of my server, which is logical.
>
Maybe just a note before you go make all kinds of changes.
With an <img> tag like above, it is not so that the server will look in
the DocumentRoot.
You have to look at it the other way around.
The browser, when it sees this tag in the current page, is going to
"compose" a URL to retrieve it, on the base of :
- the URL at which it retrieved the current page (the one that contains
the <img> tag
- removing the last component (iow the name of the page itself)
- then substituting the "image.gif" part
In other words, if the current page was retrieved at :
http://yourserver.com/SEDO/subdir/mypage.html
and that page contains the tag above, then the browser will retrieve the
image at
http://yourserver.com/SEDO/subdir/image.gif
The server has nothing to do with it, it just tries to deliver what is
requested by the browser.
Now, for your static elements like images, you have two choices :
- either you let things go as above, these requests will be forwarded to
Tomcat, will be balanced, and it means your images should be at the
corresponding locations in your Tomcat's
- or you do something at the Apache level that will prevent these URLs
to be passed to Tomcat, and you serve them locally at the Apache level.
In other words you exclude links ending in ".gif", ".jpg", ".xxx" from
the proxying.
---------------------------------------------------------------------
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.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Rewrite relative image paths in a reversed proxy setup
Posted by Bocalinda <bo...@gmail.com>.
Hey Nick.
http://172.18.0.39:8080 <http://172.18.0.39:8080/$1> is the URL of one of my
Tomcat servers.
Not my load balancer. That's what I mean with hardcoded.
I cannot put the URL of the load balancer, as I have 2 Tomcat clusters
being served by the same load balancer. Each cluster runs a different
application.
The load balancer does not know to which application the requested image
belongs,
and thus cannot forward the request to the apropriate cluster.
I don't know if this is what you meant?
2008/11/18 Nick Kew <ni...@webthing.com>
> On Mon, 17 Nov 2008 13:38:21 +0100
> Bocalinda <bo...@gmail.com> wrote:
>
> > <Location /SEDO>
> > ProxyPass balancer://mycluster1 stickysession=JSESSIONID
> > ProxyPassReverse /
> > SetOutputFilter proxy-html
> > ProxyHTMLURLMap (.*\.gif) http://172.18.0.39:8080/$1 Rie
> > </Location>
> >
> > This works, however, what I do not like is that I map the URLs to a
> > hardcoded server. What if the Tomcat instance is down? Then my images
> > won't be loaded.
>
> Where's the hardcoded server in that? The reverse proxy's role
> is to map *away from* any hardcoded paths, *into* an address -
> often a relative one - that resolves to the proxy.
>
> The above looks wrong to me.
>
>
> --
> Nick Kew
>
> Application Development with Apache - the Apache Modules Book
> http://www.apachetutor.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.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
Re: [users@httpd] Rewrite relative image paths in a reversed proxy
setup
Posted by Nick Kew <ni...@webthing.com>.
On Mon, 17 Nov 2008 13:38:21 +0100
Bocalinda <bo...@gmail.com> wrote:
> <Location /SEDO>
> ProxyPass balancer://mycluster1 stickysession=JSESSIONID
> ProxyPassReverse /
> SetOutputFilter proxy-html
> ProxyHTMLURLMap (.*\.gif) http://172.18.0.39:8080/$1 Rie
> </Location>
>
> This works, however, what I do not like is that I map the URLs to a
> hardcoded server. What if the Tomcat instance is down? Then my images
> won't be loaded.
Where's the hardcoded server in that? The reverse proxy's role
is to map *away from* any hardcoded paths, *into* an address -
often a relative one - that resolves to the proxy.
The above looks wrong to me.
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.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.apache.org
For additional commands, e-mail: users-help@httpd.apache.org