Servlet 2.5 termination response

The first optimization is small and profound, but as an example of the specification, it is quite interesting. The Servlet 2.4 specification specifies that the response should be valid in these situations, including: the content in the setContentLength method of the response has been explicitly stated, and the content has been written into the response. In this case, only your code like the following can redirect the response:
◆ Response. setHeader ("Host", "localhost ");
◆ Response. setHeader ("Pragma", "no-cache ");
◆ Response. setHeader ("Content-Length", "0 ");
◆ Response. setHeader ("Location", http://www.apache.org ");

Servlet technology ignores the header of a specific region. Because the content must be 0 bytes long, the response takes effect immediately. Before it starts, the response becomes invalid! Servlet containers usually refuse to perform this action, while Servlet 2.5 adds the "length must be greater than 0" principle.
Instance code:

The Servlet 2.4 specification requires that the request. setCharacterEncoding () method be called before the request. getReader () method is called. However, if you ignore this principle and then call the request. setCharacterEncoding () method, what are the consequences? I didn't mention it in this question specification. To make it easy, eliminate this situation now!

Cross-context sessions (sessions between different context Directories ):
Recently, the Cross-context session processing rules have been clearly stated. This rule works when Servlets assigns a request from one context to another ?? Which sessions are included in the target call process. This version enables portlets on the home page of a context directory to work with portlets in other context directories through several internal commands.

Servlet 2.5 explicitly states that resources in a context directory can access sessions in other context directories without considering where the request starts. This means that portlets can run in its own scope out of the home page, and this specification will also be applied to incompatible Serlvet containers. Expectation:

To maintain some old properties of Servlet 2.5, several major concepts have to be postponed to the next stage. They include:
◆ New input/output (NIO) support: the NIO channel is more conducive to Servlets client communication.
◆ Filter wrap-under or wrap-over semantics: Sometimes the request is packaged with a filter, and/or the response object is used to modify the method behavior or enable a new method. How should I package this package together with the server's packaging of requests and responses?
◆ Welcome Servlets file: should the index serve as a welcome file? Before that, the answer is yes. However, the specification does not clearly describe how to use this function, especially when no index is available.
◆ Dispatch Rules for welcome documents: the details of how to dispatch welcome documents are not fully described, but some open gaps are left to address incompatibility issues.
◆ Select the default page after login: if the user accesses the Servlet login page through their bookmarks, where should the page be switched after successful login? This issue has not yet been clearly stated.
◆ User topic log: After the website is correctly registered, the Servlet cannot trust the user without the traditional login method.

1. DoFilter method in Servlet
2. Configure Servlet Filter
3. Install Servlet and JSP development tools
4. Java Servlet getting started
5. What is a Servlet filter?