Javaweb notes Four

Get form data:
1. String str = Request.getparameter (string)//The form value is obtained according to table sole name, if it is more than one key value with the same name, the first value is returned.
2, string[] str= request.getparametervalues (String)//based on the table sole name get the form value of the array, the same name key-value pairs are encapsulated as a group.

Required conditions for uploading files:
1. Form must be submitted by post
2, the form must be added enctype= "Multipart/form-data", the request flow message body format to the message format, mail format to the client's files,
Submitted to the server in binary mode.
3, in the servlet, must add @multipartconfig annotations, tell the server, in the message format to parse the request message body.

Request forwarding only sends a request, forwarding the resources of the server itself.
The forward () method means that after sending the request and response to another resource, it will not be processed any more, not including the results of its own servlet output.
The include () method means asking someone to help with the request, but this is not a complete handover, but temporarily handing over control to others, both local servlet and target resources output.
Request.getrequestdispatcher ("/page/login.html"). (Forward|include) (Request, response);

Path issues for Web applications:
Request forwarding and getting a real path are all resource lookups within the server. In/After, no project name is required.
The remaining resources are searched and linked, and the project name needs to be added after/. (page and redirect)

Differences in Request forwarding and redirection:
1, Request.getrequestdispatcher ("/page/login.html"). (Forward|include) (Request, response);
Response.sendredirect ("/webhomework/login");
2. Request to forward a request, you can share the shared data bound in the request, redirect two requests cannot be shared.
3. Request forwarding can only be forwarded to resources inside the server, and redirection may be accessed at a second time on the other server.

How state tracking works in a Web app:
1, hide the form
2. Cookies (analogue Passbook)
3. Session (Analog bank card)
4. URL Rewriting

Cookie Work Flow:
Client Access server, the server calls Response.addcookie () to add cookie information to the response object, and when the response is generated,
There is a Set-cookie key value pair in the response header, and the Set-cookie corresponding value is the cookie information. The next time the server accesses the cookie information that was previously given to the client for status tracking.
Classification of Cookies:
1, stored in the client browser cache, the browser receives the cookie information, will send the request, the server has been sent cookie information.
However, after the browser is closed, cached information, cookie information will disappear, and then send the request, there will be no cookie information, this is the default way.
2, saved in the client's file, if set the expiration time of the cookie, will be saved as a file in the client. Within the expiration range, the client browser will read the cookie file
Cookie information and then send it to the server.

Session Workflow:
The client requests the server, and the server calls the Request.getsession () method, which produces the session object that holds the current user's information. Also generates a unique identifier for the session object
SessionID. In order to manage the session objects of different users, the SessionID is the key, and the session object is the value, which is saved into a map collection.
When a response is generated, the server sends the SessionID to the client in the form of a Set-cookie response header. When the client requests the server again, it will sessionid in the cookie request header mode,
Sent to the server, the server can track the status by locating the corresponding session object from the map collection according to SessionID.
A server-side object that is specifically created to hold client information. There is a session object that is returned directly without creating a
HttpSession session = Request.getsession ();

The interaction between the client and the server can be secured by SessionID the session. SessionID is saved on the client, as long as the browser does not close can be accessed with SessionID.
When the session information disappears after closing, the server will re-generate a new session object.

Session objects also have setattribute () and getattribute (), or they can be bound to share objects in a single session. As long as the browser does not close, you can always send SessionID
To the server, find the session object, thus obtaining the shared data bound in the Session object.

Session Management: Because the HTTP protocol is a stateless protocol, each time a response is requested, the connection will be disconnected. So when a user logs on to the server,
The server assigns a session object to the user in order to save the state of the client. But after the downline, the server is not clear whether the user is offline.
This way, even if the user is offline, the server is still saving the session object for the user, so the server's expired session must be cleaned up immediately.

There are three ways of destroying a session:
1. Session timeout, set timeout time
<session-config>
<session-timeout>30</session-timeout>
</session-config>
2, call Invalidate (), forcibly destroy
3. Server crash or restart deployment

The difference between a cookie and a session:
1, the session is saved in the server, the cookie information is saved on the client.
2, the session is the server-side object, the saved information is done by the object way. Cookie information is a piece of text.
3, the use of cookies for state tracking, the client and the server interaction between the specific data. While using session for state tracking, the interaction between client and server is SessionID.
Use session mode for greater security.

URL rewriting: Because cookie information is prone to security risks, some users disable the client browser from receiving cookie information for security reasons.
As a result, the server sends the client a cookie to the client's SessionID and cannot be saved in the client browser's cache. Then when the client requests the server again,
It is also not possible to send SessionID to the server in a cookie manner. If the server is not SessionID, it will be considered a new user and cannot be traced.
The solution is URL rewriting, which forcibly appends the SessionID to the URL, so that the server can get SessionID to track the status even if the client disables cookies. is a supplement to the session.
<a href= ' ADD;JSESSIONID=HB123ASWDQ3423EASFDSF ' > Access </a>

Servletcontex (context): Entire Web application
HttpSession (session): A session interaction process
ServletRequest (Request): One request process

Monitoring the change of access data in the three objects of session,request,application
Listener implementation steps:
1. Determine the source of the event
2. Identify the Listener
3, registration, the establishment of event source and listener contact

Web listeners fall into two categories:
1. Monitor the life cycle of event source objects (create and destroy)
2. Monitoring Event Source object property changes (attribute additions and deletions)

Registration of Web listeners:
<listener>
<listener-class>com.project.util.ContextListener</listener-class>
</listener>
Servlet3 Standard, you can register with @weblistener annotations
Browser off, does not mean the session is destroyed ********

Javaweb notes Four