HTTP protocol. MD

This article goes from: HTTP protocol detailed

HTTP protocol Introduction

Hypertext Transfer Protocol (Http,hypertext Transfer Protocol) is one of the most widely used network protocols on the Internet. All WWW documents must comply with this standard. HTTP was originally designed to provide a way to publish and receive HTML pages. 1960 American Ted Nelson conceived a way to process text messages through a computer called hypertext (hypertext), which has become the foundation of the HTTP Hypertext Transfer Protocol Standard architecture. The Ted Nelson organization coordinated the World Wide Web Association (Wide) and the Internet Engineering Working Group (Internet Engineering Task Force) to work together to study and eventually release a series of RFCs, of which the famous RFC 2616 defines the HTTP 1.1.

The main features of the HTTP protocol can be summarized as follows:

• Supports client/server mode.

• Simple and fast: When a customer requests a service from the server, it simply transmits the request method and path. The request method commonly has, POST. Each method specifies a different type of contact between the customer and the server. Because the HTTP protocol is simple, the HTTP server's program size is small, so the communication speed is fast.

• Flexible: HTTP allows the transfer of any type of data object. The type being transmitted is marked by Content-type.

• No connection: The meaning of no connection is to limit the processing of only one request per connection. When the server finishes processing the customer's request and receives the customer's answer, the connection is disconnected. In this way, the transmission time can be saved.

• Stateless: The HTTP protocol is a stateless protocol. Stateless means that the protocol has no memory capacity for transactional processing. A lack of state means that if the previous information is required for subsequent processing, it must be re-routed, which may cause the amount of data to be transferred per connection to increase. On the other hand, it responds faster when the server does not need the previous information.

HTTP protocol detailed URL Chapter

HTTP (Hypertext Transfer Protocol) is a request-and-response mode-based, stateless, application-level protocol, often based on TCP connection, HTTP1.1 version of a continuous connection mechanism, the vast majority of web development, is built on the HTTP protocol on the Web application.

URL Uniform Resource Locator: (a URL is a special type of URI that contains enough information to find a resource) in the following format:

http://host[":"port][abs_path]

HTTP means to locate network resources through the HTTP protocol, the host represents a legitimate Internet host domain name or IP address; port specifies a port number, or null specifies the URI of the requested resource using the default port 80;abs_path, if no abs_ is given in the URL Path, it must be given as a "/" when it is a request URI, which is usually done automatically by the working browser.
eg
1. Input: www.guet.edu.cn
Browser automatically converted to: http://www.guet.edu.cn/
2, http:192.168.0.116:8080/index.jsp

HTTP protocol detailed request chapter

The HTTP request consists of three parts: the request line, the message header, and the request body.

The request line begins with a method symbol, separated by a space, followed by the requested URI and version of the Protocol, in the following format:

Method Request-URI HTTP-Version CRLF  

Where method means the request, Request-uri is a Uniform Resource identifier, http-version represents the HTTP protocol version of the request, CRLF indicates carriage return and newline (except for the CRLF at the end, a separate CR or LF character is not allowed).

There are several ways to request a method (all uppercase), and each method is interpreted as follows:

• Get request gets the resource identified by the Request-uri

• Post appends new data to the resource identified by Request-uri

• HEAD request Gets the response message header for the resource identified by Request-uri

• PUT Request server stores a resource and uses Request-uri as its identity

• Delete Request server deletes the resource identified by the Request-uri

• TRACE requests the server to echo received request information, primarily for testing or diagnostics

• CONNECT reserved for future use

• Options request the performance of the query server, or query for resource-related choices and requirements

Application Examples:
Get method: When a Web page is accessed by entering a URL in the address bar of the browser, the browser uses the Get method to obtain resources from the server:

GET /index.html HTTP/1.1Host:192.168.0.210HTTP/1.1 200 OKDate: Sun, 13 Nov 2016 16:37:41 GMTServer: Apache/2.2.15 (CentOS)Last-Modified: Sun, 13 Nov 2016 16:37:19 GMTETag: "2c74-13-54131563ee60b"Accept-Ranges: bytesContent-Length: 19Connection: closeContent-Type: text/html; charset=UTF-8

The Post method requires the requested server to accept the data appended to the request and is often used to submit the form.

eg：POST /reg.jsp HTTP/ (CRLF)Accept:image/gif,image/x-xbit,... (CRLF)...HOST:www.guet.edu.cn (CRLF)Content-Length:22 (CRLF)Connection:Keep-Alive (CRLF)Cache-Control:no-cache (CRLF)(CRLF)         //该CRLF表示消息报头已经结束，在此之前为消息报头user=jeffrey&pwd=1234  //此行以下为提交的数据

The head method is almost the same as the Get method, and for the response part of the head request, the information contained in the HTTP header is the same as the information obtained through the GET request. Using this method, you can obtain information about the resources identified by Request-uri without transmitting the entire resource content. This method is commonly used to test the validity of hyperlinks, whether they can be accessed, and whether they have been updated recently.

HTTP protocol Detailed response

After receiving and interpreting the request message, the server returns an HTTP response message. The HTTP response is also made up of three parts: the status line, the message header, and the response body.

The status line format is as follows:

HTTP-Version Status-Code Reason-Phrase CRLF

Where http-version represents the version of the server HTTP protocol, Status-code represents the response status code sent back by the server, and Reason-phrase represents a textual description of the status code.

The status code consists of three digits, the first number defines the category of the response, and there are five possible values:

• 1XX: Indication information--Indicates that the request has been received and continues processing

• 2XX: Success-Indicates that the request has been successfully received, understood, accepted

• 3XX: Redirect--further action is required to complete the request

• 4XX: Client Error--Request syntax error or request not implemented

• 5XX: Server-side error-the server failed to implement a legitimate request

Common status codes, status descriptions, descriptions:

• 200: Successful, all requested data is sent through the entity-body part of the response message; OK

• 301: The requested URL points to a resource that has been deleted, but the new location where the resource is located is indicated in the response message through the header position; Moved Permanently

• 302: Similar to 301, but indicates in the response message that the resource is now in a temporary new location through the site; Found

• 304: The client makes a conditional request, but the resource on the server has not changed, notifying the client by responding to this response status code; not Modified

• 400: The client request has a syntax error and cannot be understood by the server; Bad Request

• 401: Need to enter account and password authentication to access resources, this status code must be used with the www-authenticate header domain; unauthorized

• 403: The server receives the request, but refuses to provide the service; Forbidden

• 404: The server cannot find the resource requested by the client; not Found

• 500: Server internal error; Internal Server errors

• 502: The proxy server received a pseudo-response from the backend server; bad Gateway

• 503: The server is currently unable to process client requests and may return to normal after a period of time; Server unavailable

HTTP protocol detailed message header chapter

The HTTP message header includes a generic header, a request header, a response header, and an entity header.
Each header field consists of a name + ":" + a Space + value, and the name of the message header field is case-insensitive.

Generic Header

In the generic header, a small number of header fields are used for all request and response messages, but not for the transferred entity, only for the transmitted messages.

• Date Universal Header field indicates the day and time the message was generated

• Via shows the intermediate node through which the message passes

• The connection Universal header field allows the option to send a specified connection. For example, specify that the connection is contiguous, or specify a "close" option to notify the server to close the connection after the response is complete

• The Cache-control is used to specify the cache instruction, the cache instruction is unidirectional (the cache instruction appearing in the response may not appear in the request), and is independent (the cache instruction of one message does not affect the caching mechanism of another message processing), and HTTP1.0 uses a similar header domain of pragma. Cache directives on request include: No-cache (used to indicate that a request or response message cannot be cached), No-store, Max-age, Max-stale, Min-fresh, only-if-cached; Private, No-cache, No-store, No-transform, Must-revalidate, Proxy-revalidate, Max-age, S-maxage.

Request Header

The request header allows the client to pass additional information about the request to the server side, as well as the client itself.

• The Accept:accept request header field is used to specify which types of information the client accepts. Eg:accept:image/gif, indicating that the client wants to accept a resource in GIF image format; accept:text/html, indicating that the client wants to accept HTML text.

• The Accept-charset:accept-charset request header field is used to specify the character set accepted by the client. eg:accept-charset:iso-8859-1,gb2312. If the field is not set in the request message, the default is to accept any character set.

• The Accept-encoding:accept-encoding request header field is similar to accept, but it is used to specify acceptable content encoding. Eg:accept-encoding:gzip.deflate. If the domain server is not set in the request message, the client is assumed to be acceptable for various content encodings.

• The Accept-language:accept-language request header field is similar to Accept, but it is used to specify a natural language. EG:ACCEPT-LANGUAGE:ZH-CN. If the header field is not set in the request message, the server assumes that the client is acceptable for each language.

• Accept-ranges: You can request one or more child range fields for a Web page entity

• The Authorization:authorization request header domain is primarily used to prove that a client has permission to view a resource. When a browser accesses a page, if a response code of 401 (unauthorized) is received from the server, a request containing the authorization request header domain can be sent, requiring the server to validate it.

• Host (the header domain is required when sending a request) the host request header domain is used primarily to specify the Internet host and port number of the requested resource, which is typically extracted from the HTTP URL.

• User-agent: When we go online to the forum, we often see some welcome information, which lists the name and version of your operating system, the name and version of the browser you are using, which often makes a lot of people feel amazing, in fact, The server application obtains this information from the User-agent request header domain. The User-agent request header domain allows the client to tell the server about its operating system, browser, and other properties. However, this header field is not required, and if we write a browser ourselves without using the User-agent request header domain, then the server side will not be able to know our information.

• Referer: The upper level resource containing the resource currently being requested;

• If-modified-since: If the requested part is modified after the specified time, the request succeeds, and the 304 code is returned without modification

• If-unmodified-since: The request succeeds only if the entity has not been modified since the specified time.

• If-match: Only valid if the request content matches the entity.

• If-none-match: If the content does not change the return 304 code, the parameter is the server's previously sent ETag, and the server responded to the etag compared to determine whether the change.

An example of a request header:
Get/form.html http/1.1 (CRLF)
Accept:image/gif,image/x-xbitmap,image/jpeg,application/x-shockwave-flash,application/vnd.ms-excel,application /vnd.ms-powerpoint,application/msword,/ (CRLF)
ACCEPT-LANGUAGE:ZH-CN (CRLF)
Accept-encoding:gzip,deflate (CRLF)
if-modified-since:wed,05 Jan 11:21:25 GMT (CRLF)
if-none-match:w/"80b1a4c018f3c41:8317" (CRLF)
user-agent:mozilla/4.0 (compatible; MSIE6.0; Windows NT 5.0) (CRLF)
Host:www.guet.edu.cn (CRLF)
Connection:keep-alive (CRLF)
(CRLF)

Response header

The response header allows the server to pass additional response information that cannot be placed in the status line, as well as information about the server and the next access to the resources identified by Request-uri.

• The Location:location response header field is used to redirect the recipient to a new location. Location response header fields are commonly used when changing domain names.

• The Server:server response header field contains the software information that the server uses to process the request. Corresponds to the User-agent request header field.

• Age: Estimated time from original server to proxy cache (in seconds, non-negative)

• Vary: Tells the downstream agent whether to use the cache response or request from the original server.

• Via: Tells the proxy client where the response was sent.

• Www-authenticate: Indicates the authorization scheme that the client request entity should use

Entity Header

Both request and response messages can send an entity. An entity consists of an Entity header field and an entity body, but it does not mean that the entity header fields and entity bodies are sent together, and only the entity header fields can be sent. The entity header defines the meta-information about the entity body (eg: there is no entity body) and the resource identified by the request.

• The Content-encoding:content-encoding Entity header field is used as a modifier for the media type, and its value indicates the encoding of additional content that has been applied to the entity body, thus obtaining the media type referenced in the Content-type header field. The corresponding decoding mechanism must be used. Content-encoding This method of compressing the document, Eg:content-encoding:gzip

• The Content-language:content-language Entity header field describes the natural language used by the resource. The domain is not set and the entity content is considered to be available to all language readers.

• The Last-modified:last-modified Entity header field is used to indicate the last modification date and time of the resource.

• The Expires:expires Entity header field gives the date and time when the response expires. In order for a proxy server or browser to update the cache after a period of time (once again accessing pages that have been visited, loading directly from the cache, shortening response times, and reducing server load), we can use the Expires entity header domain to specify when the page expires. eg:expires:thu,15 SEP 2006 16:23:12 GMT HTTP1.1 clients and caches must treat other illegal date formats (including 0) as expired. Eg: in order to let the browser do not cache the page, we can also take advantage of the Expires entity header domain, set as 0,jsp in the program as follows: Response.setdateheader ("Expires", "0");

For more information, see: HTTP Header
Extended Learning: Expanding learning

A complete HTTP request processing process:

2. Establish or process a connection: receive a request or deny a request;

4. Receiving request: The process of receiving a request from a host request packet on a network for a specific resource;

6. Processing request: To parse the request message, to obtain the resources requested by the client and the request method and other relevant information;

8. Access resource: Gets the requested resource in the request message;

10. Building Response messages:

12. Send Response message:

14. Logging:

HTTP protocol. MD