Re: Session stickiness over HTTP and HTTPS
On Tue, Dec 08, 2009 at 12:56:03AM +0100, Holger Just wrote: > On 07.12.09 23:19, Anthony Urso wrote: > > Hi: > > > > I am looking for advice on the best way to load-balance HTTP and HTTPS > > traffic such that once a session is established with either protocol, > > haproxy continues to send new requests from that session to the same > > web server. > > > > Is this a common use case? > > This indeed pretty common (although, I tend to avoid this for the sake > of simplicity using cookie-based sessions et al.) > > However, as HTTP is a stateless protocol by definition, which does not > inherently have the concept of a session, you have to decide for > yourself (or your app) what exactly a session makes. Exactly ! When I have to do this, I use stunnel to transform HTTPS into HTTP, and just use the same cookie for both services (most often both protocols point to the same frontend/backend anyway). Using a source address is generally fine on LANs because PCs don't change their IP often. But it's not practical on the net where you can generally find approximately 5% of your clients who regularly come with a different IP address because of the proxy farms they have to go through. Regards, Willy
Re: Session stickiness over HTTP and HTTPS
On 07.12.09 23:19, Anthony Urso wrote: > Hi: > > I am looking for advice on the best way to load-balance HTTP and HTTPS > traffic such that once a session is established with either protocol, > haproxy continues to send new requests from that session to the same > web server. > > Is this a common use case? This indeed pretty common (although, I tend to avoid this for the sake of simplicity using cookie-based sessions et al.) However, as HTTP is a stateless protocol by definition, which does not inherently have the concept of a session, you have to decide for yourself (or your app) what exactly a session makes. Using this info you can then tell Haproxy how to match a specific stateless request from a client and send it to the correct server which then holds its session data. For some well-documented examples see the architecture guide. [1] Additionally, it is always a good idea to put the configuration manual [2] under your pillow at night ;) > I see that section 3.1 in the configuration guide discusses using > stunnel for this, but it's not clear whether haproxy will choose the > sticky server based on stunnel's X-Forwarded-For header or it will > choose the destination by the stunnel machine's address? As stated above, this is up to you. In this case I think, it makes only sense to have it use the X-Forwarded-For header of stunnel. You can configure both. --Holger [1] http://haproxy.1wt.eu/download/1.3/doc/architecture.txt [2] http://haproxy.1wt.eu/download/1.3/doc/configuration.txt
Re: Session stickiness over HTTP and HTTPS
> Is this a common use case? Yes. > I see that section 3.1 in the configuration guide discusses using > stunnel for this, but it's not clear whether haproxy will choose the > sticky server based on stunnel's X-Forwarded-For header or it will > choose the destination by the stunnel machine's address? You can balance on X-Forwarded-For or sourceip (you want x-forwarded-for). You could also inject cookies to archieve stickyness. Just read the documentation. ;) Best regards, Craig
Session stickiness over HTTP and HTTPS
Hi: I am looking for advice on the best way to load-balance HTTP and HTTPS traffic such that once a session is established with either protocol, haproxy continues to send new requests from that session to the same web server. Is this a common use case? I see that section 3.1 in the configuration guide discusses using stunnel for this, but it's not clear whether haproxy will choose the sticky server based on stunnel's X-Forwarded-For header or it will choose the destination by the stunnel machine's address? Thanks, Anthony
