-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 André,
André Warnier wrote: | Regarding your questions about why I am concerned about knowing if the | session-id that is supplied in the JSESSIONID cookie matches the | session-id of the real current session : | | Imagine that a first browser request starts a session, identified by | session-id #1, and creates a corresponding browser JSESSIONID cookie | containing #1. [snip] | The previous session has expired on the server, so sess is a new | session, with session-id #2. | And now the application tries to retrieve, from sess, one of the | attributes it stored in the session earlier. | It will most probably get a null, which means that the atribute does not | exist, which fact may be significant to the application. That's why you should write your application to be tolerant of data disappearing. If you are using the session as a cache, then you just go ahead and re-load the data you need. If you are storing important information in the session that, say, comes from the user, then you have to show them an "uh, oh" page and tell them to restart whatever flow requires valid session data. This is how good webapps are written. Note that detecting the change in session id is not particularly useful in the situation. The best you could do is to fail in exactly the same way as if you had found a null session value. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhQfbAACgkQ9CaO5/Lv0PBBIwCgvndbfFLVxxlLkY8JQPTswkZ0 2wYAninJ4Ci9F9murmPtO+jR83tuepUq =xhGc -----END PGP SIGNATURE----- --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
