Author: Cherami type: Translation email: cherami@javaresearch.orgHTTP protocol is a stateless protocol, but for now web applications, we often need to record the link between a series of requests from a particular client. There are already many technologies that have a lot of session tracking, but it is not very convenient to use for programmers. The Servlet specification defines a simple HttpSession interface to facilitate session tracking of the Servlet container without requiring the details of the developer to pay attention to the implementation. In general, there are two most common session tracking mechanisms, one is the URL rewrite. Use URL rewrite to perform session tracking with the client's access. URL rewriting includes data that can be interpreted to the URL path to add some containers. Specifications require that the session ID must be encoded in the URL path, the parameter name must be jsessionID, for example: http://www.myserver.com/catalog/index.html;jsessionID=1234 The other is the most common cookie, specification All servlets are required to support cookies. The container sends a cookie to the client, and the client returns the cookie to the server in the request in the same session. The name of the session tracking cookie must be jsessionID. A new session function is an SSL session. SSL (Secure Sockets Layer, Security Sockets) is an encryption technology used by HTTPS protocol, built-in session tracking, and servlet containers can be very easy to use. Session tracking. (However, HTTPS is not a specification requires the protocol that the servlet must support) because HTTP is a protocol based on request response, so the session is only newly established after the client is added. A session is added when the session tracking information is successfully returned to the server to indicate the session to establish a session. If the client does not join a session, the next request will not be considered part of the session. How to do not know the session or the client selection does not join a session, then the session is considered new. Developers must design their own session processing status in their application, where there is no join session, where you can't join the session and where you don't need to join the session. Specifications require httpsession that is valid at the application or servlet context, such as cookie, the underlying mechanism of the creation session, can be shared in the context, but for those exposed objects, and more importantly those attributes of objects cannot be shared in context. For the binding of the properties of the session, any object can be bound to a naming property. The bound property object is also visible for other servlets in the same servletContext and in the same session processing. Some objects require notification when they are being added sessions or being removed from the session, such information can be obtained by making the object implementation HttpSessionBindingListener interface. This interface defines that two methods are used to mark the bind to sessions or remove from the session. The valuebound method is called before the object passes through GetAttribute, and the valueunbound method can not be called after the object is not available through GetAttribute. Since HTTP is a stateless protocol, there is no obvious signal when the client is no longer active, which means that only one mechanism can be used to indicate that the client is no longer active: timeout. The default time limit for the session is defined by the servlet container and can be obtained by getMaxInactiveInterVal through httpsession. Developers can also set up using the SetMaxInactiveInterval method. These methods returned by seconds. If the time limit is set to -1, then it means never It will time out.
