mirror of
http://git.haproxy.org/git/haproxy.git/
synced 2025-01-21 21:12:47 +00:00
bf47aeb946
This patch has 2 goals : 1. I wanted to test the appsession feature with a small PHP code, using PHPSESSID. The problem is that when PHP gets an unknown session id, it creates a new one with this ID. So, when sending an unknown session to PHP, persistance is broken : haproxy won't see any new cookie in the response and will never attach this session to a specific server. This also happens when you restart haproxy : the internal hash becomes empty and all sessions loose their persistance (load balancing the requests on all backend servers, creating a new session on each one). For a user, it's like the service is unusable. The patch modifies the code to make haproxy also learn the persistance from the client : if no session is sent from the server, then the session id found in the client part (using the URI or the client cookie) is used to associated the server that gave the response. As it's probably not a feature usable in all cases, I added an option to enable it (by default it's disabled). The syntax of appsession becomes : appsession <cookie> len <length> timeout <holdtime> [request-learn] This helps haproxy repair the persistance (with the risk of losing its session at the next request, as the user will probably not be load balanced to the same server the first time). 2. This patch also tries to reduce the memory usage. Here is a little example to explain the current behaviour : - Take a Tomcat server where /session.jsp is valid. - Send a request using a cookie with an unknown value AND a path parameter with another unknown value : curl -b "JSESSIONID=12345678901234567890123456789012" http://<haproxy>/session.jsp;jsessionid=00000000000000000000000000000001 (I know, it's unexpected to have a request like that on a live service) Here, haproxy finds the URI session ID and stores it in its internal hash (with no server associated). But it also finds the cookie session ID and stores it again. - As a result, session.jsp sends a new session ID also stored in the internal hash, with a server associated. => For 1 request, haproxy has stored 3 entries, with only 1 which will be usable The patch modifies the behaviour to store only 1 entry (maximum). |
||
|---|---|---|
| .. | ||
| design-thoughts | ||
| internals | ||
| acl.fig | ||
| architecture.txt | ||
| configuration.txt | ||
| gpl.txt | ||
| haproxy-en.txt | ||
| haproxy-fr.txt | ||
| haproxy.1 | ||
| lgpl.txt | ||
| queuing.fig | ||