-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Konstantin,
On 7/14/2011 10:53 AM, Christopher Schultz wrote: > On 7/14/2011 10:40 AM, Konstantin Kolinko wrote: >> >> I cannot say without reading the letter of the spec. > > I'll take a look. Servlet 3.0 section 14.4.10 is the only place I can see that cookie-config is mentioned at all. Unfortunately, it's shown in an image and therefore not findable using text search. :( It doesn't show that cookie-config has any sub-elements, either (just that they exist, it just doesn't show them). So, we have to turn to the XML Schema documentation for the element. The parent schema, http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd, says nothing because the definitions come from http://java.sun.com/xml/ns/javaee/web-common_3_0.xsd, where cookie-config is defined along with it's sub elements, including <max-age>: <xsd:element name="max-age" type="javaee:xsdIntegerType" minOccurs="0"> <xsd:annotation> <xsd:documentation> The lifetime (in seconds) that will be assigned to any session tracking cookies created by this web application. Default is -1 </xsd:documentation> </xsd:annotation> </xsd:element> That's pretty much all we have to go on. Since it's a cookie property, the server has no control over it after the initial Set-Cookie response header. That is, the client controls the actual expiration of the cookie as it sees fit. java/org/apache/catalina/connector/Request.doGetSession (and, later, java/org/apache/catalina/connector/Request.changeSessionId) are responsible for actually creating the session cookies and then adding them to the response. I don't see any logic in there for checking the max-age and re-sending the cookie to update the client. The question, though, is what is the intent of the setting? There are two ways to interpret <cookie-config><max-age>: 1. The value is used to set an absolute maximum age of the cookie, relative to the creation of the session. The cookie expires after that, and the session is effectively lost after that. The semantics here are of a server session with a client-enforced expiration some fixed time in the future, regardless of how recently the user visited the server. 2. The value is used to set a sliding maximum age of the cookie, essentially mirroring the server-side behavior with a client-enforced session expiration (by proxy via the cookie). #1 seems like it could be useful if you wanted a hard-maximum on the length of the session, like "in 10 hours, you're done no matter what". #2 seems like it solves a historically spec-ignored situation: allowing cookie-based sessions to survive a browser restart. When using URL rewriting, the session only expires if the server says it does, and this allows cookie-based session tracking to enjoy the same benefits. If #2 is the intended behavior, then this is a bug in Tomcat. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4gU5MACgkQ9CaO5/Lv0PAoAACfW3jw8bcuaUze4b2+EtEUP6eV PU0An0tSpjNAz2zKnTwY56vFHj16AE2x =ZpJv -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
