-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Rainer,
On 7/23/14, 4:10 PM, Rainer Jung wrote: > Am 23.07.2014 um 21:03 schrieb Christopher Schultz: > >> On 7/23/14, 1:49 PM, Rainer Jung wrote: > >>> The other case, a request with an invalid session ID accessing >>> a tomcat instance with activation disabled can IMHO be handled >>> by a filter that >>> >>> - checks whether the request has a valid session using >>> getSession(false), if it has one, let the request proceed >>> >>> - checks activation state, if "active", let the request >>> proceed >>> >>> - checks the request method, if not GET, let the request >>> proceed >>> >>> - otherwise: >>> >>> - set the session cookie, e.g. JSESSIONID the an empty value - >>> issue an external redirect to the same request URL - optional >>> redirect loop detection: add a query string param or cookie >>> that gets the local jvmRoute appended during each redirect. >>> Before doing the redirect, check that the local jvmRoute is not >>> already part of that token (we have already been here before) >>> >>> This would not really interfere with your saved requests: they >>> would get a redirect which the browser follwos automatically >>> and after that you will observe the normal behavior. >> >> This is exactly what I have implemented -- as a Filter since we >> can insert it before SecurityFilter intercepts the requests -- >> and my tests suggest that it will work correctly. >> >> I added code to strip-out any ;jsessionid path parameter from the >> URL > > ACK > >> if it exists, but haven't done any of the redirect loop >> detection (yet). I think the loop detection is going to have to >> keep a running list of visited nodes which, in large clusters, >> could grow very large especially if the node names are long. I'll >> post my code when it's a little more featureful. > > As long as nothing goes wrong, the first redirect - having no more > session info - should not end up in getting redirected as well, > because it should only be send to an active node by mod_jk. So you > can even stop redirecting if you detect, that it already happened > once. For a large cluster that might be better. > > Multiple might happen (didn't check the code), if all active > members are in error state. Even then one would not like to produce > many of those redirects for one request, so again, only allowing > one redirect might be the right solution. That's a good thought, and simplifies things. The request parameter could then just be a boolean flag and not actually identify the node that produced the redirect: any node considering redirecting simply would not redirect if that flag had been set. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJT0CW9AAoJEBzwKT+lPKRYPlsQAJUFuK+nBO3jty473UgIqZCK of3S+yux9FxzowMUCIkwnXi61zazDJqOmEuPO/qvWdmxPb9/cEj8U7h9V8lC04zI zc3Z0Fq4m9mMgmMmhi4MEu2vXuW01pw6YaePxyMsP0LqNxCb6xvp0UkQsBDCEd46 X7GJpt3q1MreFCD4lPYqDhiKm5oR3HqsJC+CmajpcfWMTg5VT4k8jX9HM5xS1p7N bvCYbxFB8I7/QMOG7cQ2+Dok5C9h/j9MGQvlL3UXCgWS7LRLPBFNzoZn9UfUhZNz VsEWJspIn8KETP02AGV5vFd00ydpi53ZwlySUwjznrNixrPt7R4O+yhR5dB8tyNm Yx8NA1rtWKVoKOeBiB/r3WBnNWg2f+AzND92DmaAvRZevSoOK1OY6oeAYnoBYVg6 2Oipes/dUEalq+oeNqAh2/jAmzo195MuOfo/vCDwGLTE26j+sjEDFRqKOcnR0EmO g2Y13hFa60ueswrI5Ixq5beFz0SRd2St6V6FBQRl7+7TRPI9wwEbYnZwT3iCL4qT 8jWP7XvWWOySLM7rEKldbcVpEElobWVtfhhjLWjQWhjXgnsdOAj0elfAzWAS+kFq YeKJRHCbi8dka5TGv31fhfGSNgTnlUyMaZ+J+idzCNw0O+yBgIgZWPMPUsC9RqDq 5gBLNkXTUQb+VSzBbteQ =Uwwp -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
