httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: [users@httpd] Rewrite relative image paths in a reversed proxy setup
Date Tue, 18 Nov 2008 12:57:39 GMT
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 <bocalinda@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 <dan@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


Mime
View raw message