HTTP protocol Specific explanation

URL of the HTTP protocol

An HTTP url (a URL is a special type of URI.) A format that includes sufficient information to find a resource) such as the following:
http://host[":" Port][abs_path]
HTTP means to locate network resources through HTTP protocol;
Host represents a legitimate Internet host domain name or IP address;
Port to specify a port number. The default port80 is used for null;
ABS_PATH Specifies the URI of the requested resource;
If Abs_path is not given in the URL, then it is used as the request URI.
Must be given in the form of a "/", usually the work browser itself to help us finish.
eg
1. Input: www.guet.edu.cn
The browser actively converts itself to: http://www.guet.edu.cn/
2, http:192.168.0.116:8080/index.jsp

Ii. contents of the HTTP protocol

Request and Response messages use the generic message format of RFC 822 [9] for transferring
Entities (the payload of the message). Both types of message consist of a start-line,
Zero or more header fields (also known as "headers"),
An empty line (i.e., a, and nothing preceding the CRLF)
Indicating the end of the header fields, and possibly a message-body.
Generic-message = Start-line
* (Message-header CRLF)
CRLF
[Message-body]

The HTTP protocol request and response content consists of three parts: row (Request line and status line), header (message header), body (message body)
Between the message header and the message body, separated by a CRLF (carriage return and line break), indicates the end of the header field.

2.1 rows (start-line)

(2.1.1) Request Line (Request-line)

The request line begins with a method symbol. separated by a space. Followed by the requested URI and the version number of the Protocol,
The format is as follows: Method Request-uri http-version CRLF
The method means the request;
Request-uri is a uniform resource identifier;
Http-version represents the requested HTTP protocol version number, which currently uses 1.1.
The CRLF represents a carriage return and a newline (except as CRLF at the end.) Do not agree to the presence of a separate CR or LF character).

There are several ways to request methods (all capitalized), such as the following:
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 requests that the server delete the resource identified by Request-uri
TRACE requests that the server Echo received request information. Mainly used for testing or diagnosis
CONNECT reserved for future use
Options requests the performance of the query server, or queries for resource-related choices and requirements

Application Examples:
Get method: Enter the URL in the browser's address bar to access the Web page. The browser uses the Get method to get resources to the server,
Eg:get/form.html http/1.1 (CRLF)

The Post method requires that the requested server accept the data appended to the request. Often used to submit a form.
eg:post/reg.jsp http/(CRLF)

(2.1.2) status line (Status-line)

The line of the response is called the status line, as in the following format: Http-version status-code reason-phrase CRLF
Of Http-version represents the version number of the Serverhttp protocol.
Status-code indicates the response status code sent back by the server;
Reason-phrase represents a textual description of the status code.
The status code is made up 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-requires further action to complete the request
4xx:client ERROR--Request syntax error or request not implemented
5xx:server-side error--server failed to implement a legitimate request
eg:http/1.1 OK (CRLF)

2.2 Header (Message header)

The HTTP header field contains class 4: General-header; Request-header; Response-header; Entity-header.

(2.2.1) Regular header (general header)

General-header is available for request and response, but not for entity.
The common header domain includes header fields that both request and response messages support,
Includes Cache-control, Connection, Date, Pragma, transfer-encoding, Upgrade, Via.

Cache-control
CACHE-CONTROL Specifies the caching mechanism that requests and responses follow.
Setting Cache-control in a request message or response message does not alter the caching process in a message processing process.
The cache instruction at the time of the request contains No-cache, No-store, Max-age, Max-stale, Min-fresh, only-if-cached,
The directives in the response message contain public, private, No-cache, No-store, No-transform, Must-revalidate,
Proxy-revalidate, Max-age.

No-cache is often used to indicate that it is not cached.

Date
The Date header field represents the time the message was sent, and the descriptive narrative format of the time is defined by rfc822.
For example, Date:mon,31dec200104:25:57gmt.

Date descriptive time represents the world standard, converted into local time, need to know the user's time zone.

Pragma
The pragma header domain is used to include implementation-specific instructions, most often using Pragma:no-cache.
In the http/1.1 agreement, it has the same meaning as Cache-control:no-cache.

(2.2.2) Requests header (request header)

The request header field may include the following fields Accept, Accept-charset, accept-encoding,
Accept-language, Authorization, from, Host, If-modified-since,
If-match, If-none-match, If-range, If-range, If-unmodified-since,
Max-forwards, Proxy-authorization, Range, Referer, User-agent.

Header	explain	Demo Sample
Accept	Specify what type of content the client can receive	Accept:text/plain, text/html
Accept-charset	The set of character encodings that the browser can accept.	Accept-charset:iso-8859-5
Accept-encoding	Specifies the type of webserver return content compression encoding that the browser can support.	Accept-encoding:compress, gzip
Accept-language	Browser-acceptable language	Accept-language:en,zh
Host	Specify the domain name and port number of the requested server	Host:www.zcmhi.com
From	Email from the user who made the request	From: [Email protected]
Referer	The address of the previous Web page. The current request page is immediately followed by the route	Referer:http://www.zcmhi.com/archives/71.html
User-agent	The content of the user-agent includes the user information that made the request	user-agent:mozilla/5.0 (Linux; X11)

(2.2.3) response header (Response header)

The Response header field agrees that the server passes additional information that cannot be placed on the status line.
These domains mainly describe the information of the server and Request-uri further information.
The Response header field includes age, location, proxy-authenticate, public,
Retry-after, Server, Vary, Warning, Www-authenticate.

Header	explain	Demo Sample
Age	Estimated time (in seconds, non-negative) formed from the original server to the proxy cache	Age:12
Location	Used to redirect the receiver to the location of the non-request URL to complete the request or identify the new resource	Location:http://www.zcmhi.com/archives/94.html
Proxy-authenticate	It indicates the authentication scheme and the number of references on the URL that can be applied to the agent	Proxy-authenticate:basic
Server	Webserver software name	server:apache/1.3.27 (Unix) (Red-hat/linux)
Retry-after	Suppose the entity is temporarily undesirable. Notifies the client to try again after a specified time	retry-after:120
Vary	Tells the downstream agent whether to use the cache response or the original server request	Vary: *
Warning	Warning about possible issues with the entity	warning:199 Miscellaneous Warning
Www-authenticate	Indicates the authorization scheme that the client request entity should use	Www-authenticate:basic

(2.2.4) solid Head (entity header)

The Entity header field includes the original information about the entity, including allow, Content-base, content-encoding,
Content-language, Content-length, Content-location, CONTENT-MD5,
Content-range, Content-type, Etag, Expires, Last-modified, Extension-header.

Header	explain	Demo Sample
Allow	A valid request behavior for a network resource is returned with a 405	Allow:get, HEAD
Content-encoding	Webserver supports the return content compression encoding type.	Content-encoding:gzip
Content-language	The language of the response body	Content-language:en,zh
Content-length	The length of the response body	content-length:348
Content-location	There is an alternative to the requested resource, and an address.	Content-location:/index.htm
Content-md5	Returns the MD5 checksum value of a resource	content-md5:q2hly2sgsw50zwdyaxr5iq==
Content-range	The byte position of this section in the entire return body	Content-range:bytes 21010-47021/47022
Content-type	Returns the MIME type of the content	content-type:text/html; Charset=utf-8
ETag	The current value of the entity label of the request variable	ETag: "737060cd8c284d8af7ad3082f209582d"
Expires	Date and time when the response expires	Expires:thu, 16:00:00 GMT
Last-modified	Last modified time of request resource	Last-modified:tue, 12:45:26 GMT

See here you may be very strange, why there is no cookie,content-disposition such a common information head?!

Here I say, content-disposition is not part of the HTTP standard. However, it is defined in other RFC documents (RFC1806).
And what about cookies? First look at what cookies are for: cookies and sessions are used to resolve stateless issues in the HTTP protocol.
, because the designers of HTTP did not intend to let HTTP have a stateful nature. So cookies such things are certainly impossible
is part of the HTTP standard.

In fact. They all belong to the above mentioned: Extension-header.

2.3 Body of messages (message body)

The Message-body (if any) of a HTTP message is used to carry the entity-body associated
With the request or response. The message-body differs from the Entity-body a
Transfer-coding has been applied, as indicated by the Transfer-encoding header field.
(Message-body = Entity-body
| Entity-body encoded as per transfer-encoding)

Between the message header and the message body is a blank line, which is important. It indicates that the message header is over, followed by the message body.
Typically post-request message body, content format: param1=value1?m2=value2
The message body of the response is common to the message body of HTML and JSON,
JSON format: {"Key1": "Value1", "Key2": "Value2"}
HTML format:
<! DOCTYPE html>
...
...

Iii. references (1)

Type=5 "style=" Color:rgb (51,122,183); Text-decoration:none "> Status Code Specific Information
(2) Information on many other message headers
(3) http/1.1 Document
(4) RFC Archives Original transfer from: http://beadlechen.github.io/

HTTP protocol Specific explanation