Hi, here:
http://grokbase.com/t/tomcat/users/13bvsbwb8s/multiple-servers-and-digest-authentication the same problem is described and the recommended solution is to use sticky load balancing. But, the problem in a tomcat cluster is that the session ID is generated after a successful authentication. The first http response (401 with Authentication Header) does not contain a session ID. How should sticky load balancing be configured or how to enforce session id generation before authentication? Regards Olschi Von: Sascha Skorupa Gesendet: Mittwoch, 4. März 2015 16:21 An: 'users@tomcat.apache.org' Cc: Sebastian Olscher Betreff: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem Hi, because of changes in the HTTP digest implementation within the JDK 8 (https://bugs.openjdk.java.net/browse/JDK-8010505), we are forced to migrate from tomcat 6 to 7. The problem is that we have a tomcat cluster (several tomcats behind an apache/modjk server) and we cannot guarantee that both HTTP requests resulting from the digest authentication are sent to the same tomcat instance. In Tomcat 6 it was no problem because nonces were not cached or rather unknown nonces did not force a re-authentication like it is done in the DigestAuthenticator of Tomcat 7: if (info == null) { // Nonce is valid but not in cache. It must have dropped out // of the cache - force a re-authentication nonceStale = true; } Some clients have the problem that the second 401 response to the request with authorization header leads to an authentication failure although the credentials are correct. Other clients like e.g. JMeter keep trying to send authorisation header, if stale is true, until a HTTP 200 is responded. So, what is the recommendation here? How to use Digest authentication within tomcat clusters if nonces are cached in a map within DigestAuthenticator? Best regards Sascha
