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 <[EMAIL PROTECTED]>

> 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 <[EMAIL PROTECTED]>
>>
>>  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 <[EMAIL PROTECTED]>
>>>>
>>>>  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 <[EMAIL PROTECTED]>
>>>>>
>>>>> 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 <[EMAIL PROTECTED]>
>>>>>>>
>>>>>>>>  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: [EMAIL PROTECTED]
>>>>>>>>>> "   from the digest: [EMAIL PROTECTED]
>>>>>>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>> 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: [EMAIL PROTECTED]
>>>>>>>>  "   from the digest: [EMAIL PROTECTED]
>>>>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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: [EMAIL PROTECTED]
>>>>>>>  "   from the digest: [EMAIL PROTECTED]
>>>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>  ---------------------------------------------------------------------
>>>>>>>
>>>>>> 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: [EMAIL PROTECTED]
>>>>>>  "   from the digest: [EMAIL PROTECTED]
>>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>>
>>>>>>
>>>>>>
>>>>>>  ---------------------------------------------------------------------
>>> 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: [EMAIL PROTECTED]
>>>  "   from the digest: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> 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: [EMAIL PROTECTED]
>  "   from the digest: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Reply via email to