you also have the option to put the redirect in pound ......
Em 17/05/2012, às 19:51, Roberto Pimenta Jr. <[email protected]> escreveu: > > > I think that rewritelocation 2 will do the trick... but i dont have an > environment to test. > > Em 17/05/2012, às 19:42, Roberto Pimenta Jr. <[email protected]> > escreveu: > >> have you tested with rewrite location or rewrite destination? >> >> >> >> Em 17/05/2012, às 19:01, Leo Cadle <[email protected]> escreveu: >> >>> Hi List, >>> >>> >>> >>> I will reply once here to all comments. >>> >>> >>> >>> I have removed HA Proxy, it was just doing the Load Balancing while Pound >>> was doing the SSL Offload. >>> >>> I had not tried to setup an environment like this before and was following >>> a tutorial that did it this way. Once I installed Pound I could see it >>> could do the same thing on the back end but did not remove HA Proxy >>> straight away. It is now out of the picture. >>> >>> I am trying to replicate our production environment in a test scenario. Our >>> production environment uses hardware load balancers, I am trying to see if >>> I can replicate the configuration using software Load Balancers so we can >>> better test our releases. So far I have tried Microsoft ARR, which has a >>> checkbox to enable or disable this particular behaviour called ‘Reverse >>> rewrite host header’. >>> >>> The backend web server is a singe server with one IP address, it hosts >>> multiple sites answering to different subdomains. That is why we have the >>> wildcard certificate. The DNS is set correctly with all sudomains pointing >>> to the same IP. Without Pound the redirect works correctly, when pound is >>> involved the subdomain always gets rewritten to the starting subdomain. It >>> is not a problem with our redirect code, it is a simple redirect, this is a >>> replica of our production code which works correctly behind Brocade Load >>> Balancers (http://www.brocade.com/index.page) and also works behind >>> Microsoft ARR (something else is the problem with ARR). >>> >>> I have included a tcp dump that shows the rewrite taking place. >>> >>> >>> >>> Cheers, >>> >>> Leo. >>> >>> On Fri, May 18, 2012 at 4:39 AM, Roberto Geraldo Pimenta Ribeiro Junior >>> <[email protected]> wrote: >>> >>> -Are you using nginx or apache? >>> >>> -Could you send us your redirect code in the php file? >>> >>> -Why are you using pound AND haproxy? >>> >>> >>> >>> Regards, >>> >>> Roberto >>> >>> >>> >>> De: Roberto Geraldo Pimenta Ribeiro Junior >>> Enviada em: quinta-feira, 17 de maio de 2012 15:36 >>> Para: [email protected] >>> Assunto: RES: [Pound Mailing List] Wildcard Certificate and 302 redirect >>> >>> >>> >>> I completely agree. It does not seem a pound matter….. >>> >>> >>> >>> De: Jacob Anderson [mailto:[email protected]] >>> >>> Enviada em: quinta-feira, 17 de maio de 2012 12:20 >>> Para: [email protected] >>> >>> Assunto: RE: [Pound Mailing List] Wildcard Certificate and 302 redirect >>> >>> >>> >>> Hello, >>> >>> >>> >>> For my take, and my experience only, I’ve had this occur when I did not >>> have the DNS setup properly. In my case, I was not setting the >>> sd1.example.com and sd2.example.com domains back to the local IP addresses. >>> When this was the case, pound would not redirect correctly and our login >>> would never work. Once I added the local IP name service for example.com, >>> pound started to redirect properly. Our backends were tomcat servers. >>> >>> >>> >>> Just my experience, and it may not reflect what you are experiencing. Pound >>> is very touchy about DNS from what I’ve seen. >>> >>> >>> >>> -- Jake >>> >>> >>> >>> >>> >>> From: Andrzej Dopierała [mailto:[email protected]] >>> Sent: Thursday, May 17, 2012 6:43 AM >>> To: [email protected] >>> Subject: Re: [Pound Mailing List] Wildcard Certificate and 302 redirect >>> >>> >>> >>> W dniu 17.05.2012 04:16, Leo Cadle pisze: >>> >>> Hi List, >>> >>> >>> >>> I am having trouble with Pound in front of HAProxy, they are performing SSL >>> Offload and Load Balancing in front of a Web Server with multiple sites in >>> the same domain. Everything works apart from one niggling problem, when I >>> do a 302 redirect from one subdomain site to another on the webserver it >>> does not change the subdomain sent to the client. E.g. >>> https://sd1.example.com/test.php performs a 302 redirect to >>> https://sd2.example.com/result.php but instead the client is redirected to >>> https://sd1.example.com/result.php I have included my config below. I have >>> read the man pages, the mailing list and scoured google but I cannot seem >>> to find the same issue explained in a way I can make sense of. This is my >>> first time using Pound and HAProxy (I have sent the same question to the >>> HAProxy list) I am not sure where this is going wrong but have searched >>> resolutions in both software. >>> >>> >>> >>> use >>> "RewriteLocation 0" in Listeners. >>> >>> # poundctl control socket >>> >>> Control "/var/run/pound/poundctl.socket" >>> >>> >>> >>> >>> >>> ###################################################################### >>> >>> ## listen, redirect and ... to: >>> >>> >>> >>> ## redirect all requests on port 8080 ("ListenHTTP") to the local webserver >>> (see "Service" below): >>> >>> ListenHTTP >>> >>> Address 127.0.0.1 >>> >>> Port 8080 >>> >>> Client 10 >>> >>> ## allow PUT and DELETE also (by default only GET, POST and HEAD)?: >>> >>> # xHTTP 0 >>> >>> >>> >>> Service >>> >>> BackEnd >>> >>> Address 127.0.0.1 >>> >>> Port 80 >>> >>> End >>> >>> End >>> >>> End >>> >>> >>> >>> ListenHTTPS >>> >>> Address 192.168.1.80 >>> >>> Port 443 >>> >>> Cert "/etc/pound/star.staging.poli.local.pem" >>> >>> Client 20 >>> >>> Service >>> >>> BackEnd >>> >>> Address 127.0.0.2 >>> >>> Port 80 >>> >>> End >>> >>> End >>> >>> End >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> [ Wrote 60 lines ] >>> >>> ^G Get Help ^O WriteOut ^R Read File >>> ^Y Prev Page ^K Cut Text ^C Cur >>> Pos >>> >>> ^X Exit ^J Justify ^W Where Is >>> ^V Next Page ^U UnCut Text ^T To >>> Spell >>> >>> >>> >>> Regards, >>> >>> Leo Cadle >>> >>> >>> >>> Network/System Administrator >>> >>> POLi Payments >>> >>> >>> >>> Phone Numbers >>> >>> Direct: +61 3 8601 5907 >>> >>> Main: +61 3 8601 5900 >>> >>> Free: 1300 007654 >>> >>> Fax: +61 3 8601 5999 >>> >>> >>> >>> URL: http://www.polipayments.com >>> >>> >>> >>> ____________________________________________________________________________ >>> >>> This e-mail and any attachments to it (the "Communication") are, unless >>> otherwise stated, confidential. It may contain copyright material and is >>> for the use only of the intended recipient. If you have received the >>> Communication in error, please notify the sender immediately by return >>> e-mail, then delete the Communication and the return e-mail. Please do not >>> read, copy, retransmit or otherwise deal with it. Any views expressed in >>> the Communication are those of the individual sender only, unless expressly >>> stated to be those of Centricom Pty Ltd (ABN73 105 393 664). Centricom does >>> not accept liability in connection with the integrity of (or errors) in the >>> Communication, computer virus, data corruption, interference or delay >>> arising from or in respect of the Communication. >>> >>> >>> >>> >>> >>> -- >>> Regards, >>> Andrzej 'The Undefined' Dopierała >>> http://andrzej.dopierala.name/ >>> >>> >>> >>> -- >>> >>> >>> >>> Regards, >>> >>> >>> >>> Leo Cadle >>> >>> Network/System Administrator >>> >>> POLi Payments >>> >>> >>> >>> Phone Numbers >>> >>> Direct: +61 3 8601 5907 >>> >>> Main: +61 3 8601 5900 >>> >>> Fax: +61 3 8601 5999 >>> >>> >>> >>> URL: http://www.polipayments.com >>> >>> ____________________________________________________________________________ >>> >>> >>> >>> This e-mail and any attachments to it (the "Communication") are, unless >>> otherwise stated, confidential. It may contain copyright material and is >>> for the use only of the intended recipient. If you have received the >>> Communication in error, please notify the sender immediately by return >>> e-mail, then delete the Communication and the return e-mail. Please do not >>> read, copy, retransmit or otherwise deal with it. Any views expressed in >>> the Communication are those of the individual sender only, unless expressly >>> stated to be those of Centricom Pty Ltd (ABN73 105 393 664). Centricom does >>> not accept liability in connection with the integrity of (or errors) in the >>> Communication, computer virus, data corruption, interference or delay >>> arising from or in respect of the Communication. >>> >>> >>> >>> <redir.cap>
