Detailed URL
HTTP is a stateless, application-layer protocol based on requests and corresponding modes. It is often based on TCP links. HTTP 1.1 provides a mechanism for persistent connections. Most web development is built on HTTP Web applications on top of the protocol.
An HTTP URL (a URL is a special type of URI that contains enough information to find a resource) has the following format: http://host[ ":"port][path]
where http indicates that you want to pass HTTP protocol to locate network resources; host represents a legitimate Internet host domain name or IP address; port specifies a port number, if empty, the default port 80 is used; path specifies the URI of the requested resource; if path is not given in the URL, then when When it is used as a request URI, it must be given in the form of "/", but usually the browser will do this for us. For example, enter: www.guet.edu.cn in the address bar of the browser, and the browser will automatically change to http://www.guet.edu.cn/ .
HTTP request
The HTTP request is divided into three parts, namely the request line, the message header, and the request body.
The request line starts with a method symbol, separated by spaces, followed by the requested URI and the version of the protocol. The format is as follows:
Method Request-URI HTTP-Version CRLF
Among them, Method represents the request method, generally GET, POST, PUT, DELET; Request-URI is a Uniform Resource Identifier, such as /index.jsp; HTTP-Version indicates the requested HTTP protocol version, such as HTTP/1.1; CRLF indicates carriage return and line feed (except for the trailing CRLF, separate CR or LF characters). In addition to the GET, POST, PUT, DELETE mentioned above, the request methods also include TRACE, CONNECT, OPTIONS, and the explanations of each method are as follows:
| request method | meaning |
|---|---|
| GET | Request to obtain the resource identified by the Request-URI |
| POST | Append new data to the resource identified by the Request-URI |
| HEAD | Response message headers for requests to obtain the resource identified by the Request-URI |
| PUT | Request a resource stored by the server, and use the Request-URI as an indicator |
| DELETE | Request the server to delete the resource indicated by the Request-URI |
| TRACE | Request the server to send back the received request information, mainly for testing or diagnosis |
| CONNECT | reserved for future use |
| OPTIONS | Request to query the performance of the server, or to query the options and requirements related to the resource |
HTTP response
Under normal circumstances, the server will return an HTTP response message after receiving and processing the request sent by the client.
The HTTP response message is also composed of three parts: the status line, the message header, and the response body.
The format of the status line is as follows: HTTP-Version Status-Code Reason-Phrase (CRLF)
Among them, HTTP-Version indicates the version of the HTTP protocol of the server, such as HTTP/1.1; Status-Code indicates the response status code sent by the server, such as 200; Reason -Phrase represents a textual description of the status code, eg OK.- HTTP Status Code The
status code consists of three digits, the first digit defines the category of the response, which is divided into five categories:
| status code | Status code meaning |
|---|---|
| 1XX | Indication – Indicates that the request has been received, continue processing |
| 2XX | Success – Indicates that the request was successfully received, understood, accepted |
| 3XX | Redirect – further action must be taken to complete the request |
| 4XX | Client Error – The request has a syntax error or the request cannot be fulfilled |
| 5XX | Server Side Error – The server failed to fulfill a legitimate request |
HTTP message headers
Whether it is a request message or a response message, it consists of a start line (for a request message, the start line is the request line, for a response message, the start line is the status line), message headers, blank lines (only CRLF lines), and the message body. HTTP message headers include normal headers, request headers, response headers, and entity headers. Each header field is composed of name + ":" + value. The name of the message header field is case-insensitive. There can be any number of spaces before the field value (but usually a space is added before it), and multiple The same message header.
- Common Header The
common header contains header fields supported by both request and response messages, including Cache-Control, Connection, Date, Pragma, Transfer-Encoding, Upgrade, and Via.
Cache-Control: Used to specify cache directives. Caching directives are one-way (caching directives that appear in the response may not appear in the request), and are independent (caching directives for one message do not affect the caching mechanism for processing another message).
The meaning of various values of Cache-Control
| The value of Cache-Control | meaning |
|---|---|
| public | Indicates that the response can be cached by any buffer. |
| Private | Indicates that the entire or partial response message for a single user cannot be processed by the shared cache. This allows the server to describe only part of the user's response message, which is not valid for other users' requests. |
| no-cache | Indicates that the request or response message cannot be cached |
| no-store | Used to prevent important information from being released unintentionally. Sending in the request message will make the request and response messages not use the cache. |
| max-age | Indicates that the client can receive responses with a lifetime no longer than the specified time (in seconds). |
| min-fresh | Indicates that the client can receive responses with a response time less than the current time plus the specified time. |
| max-stale | Indicates that the client can receive response messages beyond the timeout period. If you specify a value for max-stale messages, the client can receive response messages that exceed the value specified in the timeout period. |
- Response headers The
response header allows the server to pass additional response information, as well as information about the server's status and further access to the resource identified by the Request-URI.
Commonly used response header information
| response header | specific meaning |
|---|---|
| Location | Used to prompt the client to redirect to a new location. The Location response header field is often used when changing the domain name. |
| Server | Contains software information that the server uses to process requests. For example, Server: Play! Framework; 1.2.3. The application service program built by 1.2.3 is in production mode. |
| Connection | |
| Proxy-Connection | |
| Set-Cookie | cookie information |
- Entity headers Both
request and response messages can carry an entity. An entity consists of the entity header field and the entity body, but it does not mean that the entity header field and the entity body should be sent together, and only the entity header field can be sent. The entity header defines meta-information about the entity body (eg, the presence or absence of an entity body) and the resource identified by the request.
Commonly used entity header information
| Entity header information | specific meaning |
|---|---|
| Content-Encoding | The compression method used to record the document. For example Content-Encoding: gzip |
| Content-Language | Describes the natural language used by the resource. If ru does not set this field, it is considered that the entity content will be available for reading in all languages |
| Content-Length | Used to indicate the length of the entity body, in bytes, in decimal |
| Content-Type | Indicates the media type of the entity body sent to the receiver, such as Content-Type:text/html;charset=ISO-8859-1, indicating that the body is an html document, using ISO-8859-1 encoding |
| Last-Modified | Used to indicate the date and time the resource was last modified. |
| Expires | Gives the date and time when the response expires. |
In order to let the proxy server or browser update the page in the cache after a period of time (when visiting the page that has been visited again, load it directly from the cache, shorten the response time and reduce the server load), we can use Expires to specify the time when the page expires . For example Expires: Thu, 15 Sep 2006 16:23:12 GMT
HTTP1.1的客户端和缓存必须将其他非法的日期格式（包括0）看作已经过期。例如，为了让浏览器不要缓存页面，我们可以将Expires设为0，jsp中程序如下：response.setDateHeader(“Expires”,”0”);