Hi, I just looked it up in the spec and there is a 3rd one as well: SSL Sessions
>From the Servlet spec: "SRV.7.1 Session Tracking Mechanisms The following sections describe approaches to tracking a user's sessions SRV.7.1.1 Cookies Session tracking through HTTP cookies is the most used session tracking mechanism and is required to be supported by all servlet containers. The container sends a cookie to the client. The client will then return the cookie on each subsequent request to the server, unambiguously associating the request with a session. The name of the session tracking cookie must be JSESSIONID. SRV.7.1.2 SSL Sessions Secure Sockets Layer, the encryption technology used in the HTTPS protocol, has a built-in mechanism allowing multiple requests from a client to be unambiguously identified as being part of a session. A servlet container can easily use this data to define a session. SRV.7.1.3 URL Rewriting URL rewriting is the lowest common denominator of session tracking. When a client will not accept a cookie, URL rewriting may be used by the server as the basis for session tracking. URL rewriting involves adding data, a session ID, to the URL path that is interpreted by the container to associate the request with a session. The session ID must be encoded as a path parameter in the URL string. The name of the parameter must be jsessionid. ..." Bernhard > -----Ursprüngliche Nachricht----- > Von: Caldarale, Charles R [mailto:[EMAIL PROTECTED] > Gesendet: Montag, 9. Januar 2006 17:26 > An: Tomcat Users List > Betreff: RE: JSessionID > > > > From: Jason Oullette [mailto:[EMAIL PROTECTED] > > Subject: JSessionID > > > > How does tomcat decide if the JSessionID will be put in a > > cookie or in the post header(url rewriting)? > > Look at the cookies attribute of the <Context> tag: > http://tomcat.apache.org/tomcat-5.5-doc/config/context.html > > > Are these the only two ways the JSessionID is passed around? > > I think so (not 100% sure), unless you invent your own mechanism. > > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE > PROPRIETARY > MATERIAL and is thus for use only by the intended recipient. If you > received this in error, please contact the sender and delete > the e-mail > and its attachments from all computers. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
