Javaweb's Grab Bag Tour (ii)

Javaweb Grab Bag Tour (ii): HTTP protocol

Note: HTTP protocol, I was summed up from the Internet

First, let's look at the interface.

Take a look at the grab bag interface (don't ask me what tools I use, let's take it slow)

Look at the request header first

Let's take a look at the analysis:

2. I only know the POST request address default/2.aspx Http1.1 (persistent connection)
4. Host: Specifies the intenet host and port number of the requested resource, which must represent the location of the originating server or gateway that requested the URL. The http/1.1 request must contain the host header domain or the system will return with a 400 status code.
6. Content-length: It's obviously the length of the content.
8. Cache-control: Tells whether all caching mechanisms can be cached and which type.
10. Accept: Specifies the type of content that the client can receive, and the order in which the content type represents the order in which the client receives it. We receive the order, text/html,application/xhtml and so on.
12. Origin: It is primarily used to indicate where the initial request was initiated.
14. User-agent:http details of the browser type that the client is running. With this header information, the Web server can determine the client browser category to the current HTTP request.
16. Content-type: Displays the content type submitted by this HTTP request. This property is typically only required for post submission.
18. Referer: Contains a URL, the user from the page represented by the URL to access the current requested page, this is a more important one, we will be based on the URL or Referer to simulate the request.
20. Accept-encoding: Specifies that the Web server that the client browser can support returns the content compression encoding type. Indicates that the server is allowed to compress the output before it is sent to the client to conserve bandwidth. The return compression format that the client browser can support is set here.
22. Accept-language: Specifies the preferred language for the HTTP client browser to display the return information.

23. When a cookie:http request is sent, all cookie values stored under that request domain are sent to the Web server.

    Speaking of which I would like to elaborate on the Cockie and session:

    When you are browsing the website, the Web server will send a small piece of information on your computer, and the Cookie will help you record the text or choices you make on the site. The next time you visit the same website, the Web server will first see if it has the last cookie information, and if so, it will be based on the contents of the cookie to determine the user, send a specific page content to you. The use of cookies is widespread, and many websites that provide personalized services use cookies to identify users and to facilitate the delivery of user-specific content, such as free email sites for web interfaces.

    In particular, the cookie mechanism uses a scheme that maintains state on the client, while the session mechanism uses a scenario that maintains state on the server side. We also see that the session mechanism may need to use a cookie mechanism to save the identity, but in fact it has other options because the server-side hold-state scheme also needs to preserve an identity on the client side. Cookie mechanism. Orthodox cookie distribution is implemented by extending the HTTP protocol, and the server prompts the browser to generate the appropriate cookie by adding a special line of instructions to the HTTP response header. However, purely client-side scripts such as JavaScript or VBScript can also generate cookies. And the use of cookies by the browser in accordance with certain principles in the background automatically sent to the server. The browser checks all stored cookies and, if a cookie declares a scope greater than or equal to the location of the resource to be requested, sends the cookie to the server on the HTTP request header of the requesting resource.

    The contents of the cookie mainly include: name, value, expiration time, path and domain. The path together with the domain constitutes the scope of the cookie. If you do not set an expiration time, the cookie will be closed for the duration of the browser session. This cookie, known as the browser session period, is referred to as a session cookie session cookie, which is not stored on the hard disk but is kept in memory, although this behavior is not regulated. If the expiration time is set, the browser will save the cookie to the hard disk, turn it off and open the browser again, and the cookies remain valid until the set expiration time expires. Cookies stored on the hard disk can be shared between different browser processes, such as two IE windows. For cookies stored in memory, different browsers have different ways of handling them.

    The session mechanism is a server-side mechanism that uses a hash-like structure (or perhaps a hash table) to hold information. When a program needs to create a session for a client's request, the server first checks to see if the client's request contains a session ID (called the session ID.), and if it is included, it has previously created a session for this client. The server will use the session ID to retrieve the session (not retrieved, a new one), if the client request does not include session ID, then create a session for this client and generate a SessionID associated with this session, The value of session ID should be a string that is neither duplicated nor easy to be found, and the session ID will be returned to the client in this response to save. This session ID can be saved by using a cookie so that the browser can automatically send the tag to the server in the interactive process. Generally the name of this cookie is similar to Seeesionid. However, a cookie can be artificially banned, and there must be other mechanisms that can still pass the session ID back to the server when the cookie is banned.

Back above:
We see a cookie (which is generated automatically when you access the server), which is like a ticket to the amusement park, you have this cookie, you can do the next thing. For example, we want to get the information that is logged into the educational administration system.

Then take a look at the parameters we requested:

The first parameter, we do not have to control, there are many browsers automatically generated.
txtUserName: User name.
TextBox2: the password.
Txtsecretcode: The verification code.
RadioButtonList1: This garbled stuff, we remember how to handle the encryption.

Now look at the header of the response:

1. Cache-control: Tell if all caching mechanisms can be cached and which type
2. Pragma: Includes implementation-specific instructions that can be applied to any receiver on the response chain.
3. Expires: The date and time when the response expires.
4. Location: Used to redirect the recipient to the non-request URL to complete the request or identify the new resource;
5. Server:web Server Software Name:

Content of the response:

We can see that the corresponding content is returned, there is a link, if we are in the same cookie down request, we will get the corresponding information.
For example: http://211.67.63.17/xs_main.aspx?xh=12042 We alone point this link will go to the login screen. We can request the corresponding information before we ask for the Session,cookie premise.

We also need to know the common response code:
1XX: Information
2XX: Success
3XX: redirect
4XX: Client Error
5XX: Server Error

In the next lecture, we will talk about the use of the clutch tool.

Javaweb's Grab Bag Tour (ii)