Re: cookie-less sessions
On Sat, Aug 6, 2011 at 12:50 PM, Willy Tarreau wrote: > On Sat, Aug 06, 2011 at 11:27:53AM +0200, Baptiste wrote: >> I made it work on our Aloha load-balancer (4.1.2) :) > > Baptiste, you should stop taking hardware with you during holidays, > it's too much temptation ;-) > Since we have the KVM version, I can work at anytime, anywhere... It's bad Anyway, I'm always keen to help people :) cheers
Re: cookie-less sessions
On Sat, Aug 06, 2011 at 11:27:53AM +0200, Baptiste wrote: > I made it work on our Aloha load-balancer (4.1.2) :) Baptiste, you should stop taking hardware with you during holidays, it's too much temptation ;-) (...) > Hank, as said before, it's not yet in HAProxy. > I can't speak on behalf of Willy, but you can ask him to kindly > include it on the next 1.5-dev release :) Cookie-based stickiness is already in the latest snapshot. I just checked in case we could rewrite the response as a cookie before sticking on it but it's not possible, rewriting is performed after sticking. I'll have to check how we can add new patterns. Cheers, Willy
Re: cookie-less sessions
On Sat, Aug 06, 2011 at 12:59:53AM -0700, Hank A. Paulson wrote: > but it would have to be a combo thing, right? - set up stick table entry on > outgoing 302 with url_param "blah" in location header then check incoming > requests for url_param "blah" and continue to stick those based on the > entry created by the initial outgoing response. I don't know if you'd do > that as 2 rules or one. Yes it's exactly that. It's possible to have up to 4 stick methods at once from what I recall. So it's possible to learn the response using a "stick store-response" rule and match in the request using "stick match". > This would be a great and wondrous thing for cookie-less clients and > decoupled servers - not to mention it may be a unique feature among > existing load balancing products. I'm sure some other products are able to do that using a bit of scripting, and that should be possible with products from Zeus or F5 which are particular known for their scripting abilities. When we implement it in haproxy, a few other products will be able to do it too :-) I'll see what I can come up with. After a bit of thinking, I'm not even sure it's useful to be able to configure the header name, as I don't expect this feature to be used on anything other than Location. Regards, Willy
Re: cookie-less sessions
I made it work on our Aloha load-balancer (4.1.2) :) PHP code on the server: cookie.php : test script.php: it creates a set-cookie with cookie name PHPSESSID and redirect the use with a URL param ID (which has the same value as the cookie id). HAProxy configuration, on my backend configuration: stick-table type string len 32 size 10K stick store-response set-cookie(PHPSESSID) stick on url_param(ID) The test: First request: $ curl -D - http://aloha/cookie.php HTTP/1.1 302 Found Date: Sat, 06 Aug 2011 09:13:45 GMT Server: Apache/2.2.16 (Debian) X-Powered-By: PHP/5.3.3-7+squeeze3 Set-Cookie: PHPSESSID=8a28f7089e9d70c3375505c9620472db; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Location: /?ID=8a28f7089e9d70c3375505c9620472db Vary: Accept-Encoding Content-Length: 68 Content-Type: text/html 192.168.10.101 Second request, with the ID on URL: $ curl -D - http://aloha/script.php?ID=8a28f7089e9d70c3375505c9620472db HTTP/1.1 200 OK Date: Sat, 06 Aug 2011 09:15:21 GMT Server: Apache/2.2.16 (Debian) X-Powered-By: PHP/5.3.3-7+squeeze3 Vary: Accept-Encoding Content-Length: 17 Content-Type: text/html 192.168.10.101 Note that I'm using the same backend, since the IP printed is the same. Let's have a look at the table now: echo "show table bk_myappli" | socat unix-connect:/var/run/haproxy.stat stdio # table: bk_myappli, type: string, size:10240, used:5 0x14b5694: key=8a28f7089e9d70c3375505c9620472db use=0 exp=0 server_id=1 Hank, as said before, it's not yet in HAProxy. I can't speak on behalf of Willy, but you can ask him to kindly include it on the next 1.5-dev release :) cheers
Re: cookie-less sessions
On Sat, Aug 6, 2011 at 9:32 AM, Willy Tarreau wrote: > Hi Baptiste, > > On Sat, Aug 06, 2011 at 09:24:08AM +0200, Baptiste wrote: >> On Sat, Aug 6, 2011 at 8:51 AM, Hank A. Paulson >> wrote: >> > On 8/5/11 3:01 PM, Baptiste wrote: >> >> >> >> Hi Hank >> >> >> >> Actually stick on URL param should work with client which does not >> >> support cookies. >> >> is the first reply a 30[12] ? >> > >> > So you are saying that stick on URL param reads the outgoing 302 and saves >> > the URL param from that in the stick table on 1.5? f so, great then problem >> > solved. If it doesn't save it on the way out from the initial redirect then >> > it won't help. >> > >> > Is the same supposed to happen with balance url_param on 1.4? >> > If not, I will switch to 1.5. If it is supposed to, it doesn't, afaict. >> > >> >> >> >> How is they user aware of the jsid or how is he supposed to send his >> >> jsid to the server? >> > >> > 302 to the URL with the jsid URL param. >> > >> > Thanks >> > >> >> >> >> Do you have a X-Forwarded-For on your proxy or can you setup one? >> >> >> >> cheers >> > >> > >> >> Well, I'm thinking of something, let me run some tests and I'll come >> back to you with a good or a bad news. > > Right now I see no way to do that. We'd need to extract the url_param > from the Location header, this would be a new pattern. I think it's > not too hard to implement. We already have url_param for the request, > we could have hdr_url_param(header_name) or something like this. > > Regards, > Willy > > Actually, I was thinking of the stuff you developed to replace the appsession by stick tables. A dirty workaround could be: - configure the application to send a response with a set-cookie and the 302/Location header, both with the same ID value. - on HAProxy, match the set-cookie of the response and store it in a stick table - when the client send request, match the URL param against the table set up above I agree that learning a URL param from a header would be cleaner ;) Hank, these options are currently not available in HAProxy, even in 1.5-dev6. I guess it will be released in the next 1.5-dev. cheers
Re: cookie-less sessions
On 8/6/11 12:32 AM, Willy Tarreau wrote: Hi Baptiste, On Sat, Aug 06, 2011 at 09:24:08AM +0200, Baptiste wrote: On Sat, Aug 6, 2011 at 8:51 AM, Hank A. Paulson wrote: On 8/5/11 3:01 PM, Baptiste wrote: Hi Hank Actually stick on URL param should work with client which does not support cookies. is the first reply a 30[12] ? So you are saying that stick on URL param reads the outgoing 302 and saves the URL param from that in the stick table on 1.5? f so, great then problem solved. If it doesn't save it on the way out from the initial redirect then it won't help. Is the same supposed to happen with balance url_param on 1.4? If not, I will switch to 1.5. If it is supposed to, it doesn't, afaict. How is they user aware of the jsid or how is he supposed to send his jsid to the server? 302 to the URL with the jsid URL param. Thanks Do you have a X-Forwarded-For on your proxy or can you setup one? cheers Well, I'm thinking of something, let me run some tests and I'll come back to you with a good or a bad news. Right now I see no way to do that. We'd need to extract the url_param from the Location header, this would be a new pattern. I think it's not too hard to implement. We already have url_param for the request, we could have hdr_url_param(header_name) or something like this. Regards, Willy but it would have to be a combo thing, right? - set up stick table entry on outgoing 302 with url_param "blah" in location header then check incoming requests for url_param "blah" and continue to stick those based on the entry created by the initial outgoing response. I don't know if you'd do that as 2 rules or one. This would be a great and wondrous thing for cookie-less clients and decoupled servers - not to mention it may be a unique feature among existing load balancing products.
Re: cookie-less sessions
Hi Baptiste, On Sat, Aug 06, 2011 at 09:24:08AM +0200, Baptiste wrote: > On Sat, Aug 6, 2011 at 8:51 AM, Hank A. Paulson > wrote: > > On 8/5/11 3:01 PM, Baptiste wrote: > >> > >> Hi Hank > >> > >> Actually stick on URL param should work with client which does not > >> support cookies. > >> is the first reply a 30[12] ? > > > > So you are saying that stick on URL param reads the outgoing 302 and saves > > the URL param from that in the stick table on 1.5? f so, great then problem > > solved. If it doesn't save it on the way out from the initial redirect then > > it won't help. > > > > Is the same supposed to happen with balance url_param on 1.4? > > If not, I will switch to 1.5. If it is supposed to, it doesn't, afaict. > > > >> > >> How is they user aware of the jsid or how is he supposed to send his > >> jsid to the server? > > > > 302 to the URL with the jsid URL param. > > > > Thanks > > > >> > >> Do you have a X-Forwarded-For on your proxy or can you setup one? > >> > >> cheers > > > > > > Well, I'm thinking of something, let me run some tests and I'll come > back to you with a good or a bad news. Right now I see no way to do that. We'd need to extract the url_param from the Location header, this would be a new pattern. I think it's not too hard to implement. We already have url_param for the request, we could have hdr_url_param(header_name) or something like this. Regards, Willy
Re: cookie-less sessions
On Sat, Aug 6, 2011 at 8:51 AM, Hank A. Paulson wrote: > On 8/5/11 3:01 PM, Baptiste wrote: >> >> Hi Hank >> >> Actually stick on URL param should work with client which does not >> support cookies. >> is the first reply a 30[12] ? > > So you are saying that stick on URL param reads the outgoing 302 and saves > the URL param from that in the stick table on 1.5? f so, great then problem > solved. If it doesn't save it on the way out from the initial redirect then > it won't help. > > Is the same supposed to happen with balance url_param on 1.4? > If not, I will switch to 1.5. If it is supposed to, it doesn't, afaict. > >> >> How is they user aware of the jsid or how is he supposed to send his >> jsid to the server? > > 302 to the URL with the jsid URL param. > > Thanks > >> >> Do you have a X-Forwarded-For on your proxy or can you setup one? >> >> cheers > > Well, I'm thinking of something, let me run some tests and I'll come back to you with a good or a bad news. cheers
Re: cookie-less sessions
On 8/5/11 3:01 PM, Baptiste wrote: Hi Hank Actually stick on URL param should work with client which does not support cookies. is the first reply a 30[12] ? So you are saying that stick on URL param reads the outgoing 302 and saves the URL param from that in the stick table on 1.5? f so, great then problem solved. If it doesn't save it on the way out from the initial redirect then it won't help. Is the same supposed to happen with balance url_param on 1.4? If not, I will switch to 1.5. If it is supposed to, it doesn't, afaict. How is they user aware of the jsid or how is he supposed to send his jsid to the server? 302 to the URL with the jsid URL param. Thanks Do you have a X-Forwarded-For on your proxy or can you setup one? cheers
Re: cookie-less sessions
Hi Hank Actually stick on URL param should work with client which does not support cookies. is the first reply a 30[12] ? How is they user aware of the jsid or how is he supposed to send his jsid to the server? Do you have a X-Forwarded-For on your proxy or can you setup one? cheers
Re: cookie-less sessions
Sorry, I meant working with balance url_param hashing On 8/5/11 2:13 PM, Hank A. Paulson wrote: I am going around again about cookie-less sessions and just want to double check that nothing works for them :) In 1.5 there is the stick on url param option, but afaict this and everything else won't work in a situation where you have two things: 1 - clients that don't support cookies. 2 - servers that don't share session info. The problem is a user goes to a server via round robin or some other algo, they arrive at server 3. Server #3 creates session X and redirs (somehow) that user to a page with a url param with jsid=X. The user goes to that url, but haproxy has no way to remember which server served that session and gave it the session id of X, so it decides to send the request to server #5, of course server #5 has no idea about session X and creates session Y and replies with a url param of jsid=Y. I have this "working" on 1.4 with appsession hashing, only because haproxy spins the user through several sessions (as described above) until one of them finally hashes to go to the same server as the previous session id, then it sticks - for a while and then when there is a long url param before the session id it switches, not sure why yet. Not perfect but better than hash by source since the bulk of the traffic is coming from a single ip proxy upstream and causes one server to be massively overloaded. Thanks for any ideas or confirmation that this is not solvable.
