On Tue, Nov 16, 2010 at 09:03:17AM +0800, Hogan Yu wrote: > Hi Willy, > Sorry for reply so late, I test my configuration according your > suggestion. It is correct that We need stunnel in front of haproxy to > decipher HTTPS. I misunderstand the configuration on https and it works. We > have lots of long connection on our application server which use GWT to do > the chat service with comet support, So I need to change the srvtimeout to > about 32s. > We are a WAP website that use access our website by mobile phone browser, > there are about one-third users browser can not support Cookie according > to our access log. When they first access the Haproxy ,the session status > is --NI and when they come back again, the status change to --VN. > ( > > The third character means: > > N : the client provided NO cookie. This is usually the case for new > visitors, so counting the number of occurrences of this flag in > the > logs generally indicate a valid trend for the site frequentation. > > > V : the client provided a VALID cookie, and was sent to the associated > server. > > The last character means: > > > N : NO cookie was provided by the server, and none was inserted either. > > I : no cookie was provided by the server, and the proxy INSERTED one. > Note that in "cookie insert" mode, if the server provides a > cookie, > it will still be overwritten and reported as "I" here. > > ) > > > The VN means that the browser don't support cookie but Haproxy already get > the mapping of jsessionid and server, so it still be transfer the request to > correct backend server.
No, it's the opposite, VN means that the browser did correctly present the cookie it learned at the previous request. The first request shows NI (No cookie presented, one cookie Inserted) and subsequent requests show VN (Valid cookie presented, No cookie inserted). So for these users that means that you don't need the appsession. The correct way to check for cookie support is to grep for requests showing the JSESSIONID in the logs and check if any of them has the NI flags. Only these ones are interesting to check because JSESSIONID means that the browser has already seen the cookie and NI means that it did not present it, which clearly indicates a lack of cookie support. And I'd bet there are between none at all and very few. Regards, Willy
