On 28.05.2009 01:42, Bill Davidson wrote:
André Warnier wrote:
Bill Davidson wrote:
...
Our application switches between them [HTTP or HTTPS] based upon
whether there is sensitive data in the page or not.
So I guess that if you did not do that, you would not be having this
issue.
Feasible
Rainer Jung wrote:
To simplify your research a little bit: you mentioned you switched
cookies off in order to use the jsessionid URL parameter to log the
session IDs.
If you keep cookies on, then you can also log the value of the
JSESSIONID cookie by using the %C syntax of Apache's CustomLog.
We're using LVS for load balancing to three separate Tomcat 6 servers.
We do not have session replication. We do use sticky load balancing,
or it wouldn't work.
The problem is, we're having some customers, specifically people in
parts of Australia and Malaysia, on wireless ISP's who are coming
Bill Davidson wrote:
They swear they aren't using proxies. I'm not sure I believe them.
Is it possible that their ISP could be redirecting ports 80 and/or 443
through a proxy without the users browser being configured to do so?
Yes.
Is there some other reason why they could be hitting us
Mark Thomas wrote:
Any reason you can't load balance based on the JVM route in the session ID?
Other than not being aware that it could be done or how to do it,
none that I know of.
Normally, we use cookies for the session id. Can LVS look at the
session id in a cookie?
Bill Davidson wrote:
Mark Thomas wrote:
Any reason you can't load balance based on the JVM route in the
session ID?
Other than not being aware that it could be done or how to do it,
none that I know of.
Normally, we use cookies for the session id. Can LVS look at the
session id in
Mark Thomas wrote:
Don't know. Never used it. Look for something in the docs around layer 7
load-balancing and/or cookies. If you are using https then your SSL will
have to be terminated at the load-balancer otherwise you won't be able
to see the session cookie or url.
Apparently LVS doesn't
Bill Davidson wrote:
...
Our application switches between them [HTTP or HTTPS] based upon
whether there is sensitive data in the page or not.
So I guess that if you did not do that, you would not be having this issue.
Feasible ?
André Warnier wrote:
Bill Davidson wrote:
...
Our application switches between them [HTTP or HTTPS] based upon
whether there is sensitive data in the page or not.
So I guess that if you did not do that, you would not be having this
issue.
Feasible ?
Non-trivial. Also, there is resistance
