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] > >
