Http Protocol Learning notes (Yan 13 teacher)

Http protocol

Importance:

1. No matter the future use of WebService or rest as a large-scale architecture, can not do without.

WebService = Http protocol + XML

Rest = HTTP protocol + Json

A variety of APIs, generally also with HTTP + Xml/json to achieve

2. And the learning of Ajax

What is a protocol (that is, the client asks the server a)

The protocols in the computer are the same as in the real world, with two or more copies. Both sides/parties comply with a common specification, which can be called a protocol. The computer is able to communicate all over the world, the agreement is to work, if there is no agreement, the computer said each word, who can not understand.

FTP, HTTP, SMTP, POP, TCP/IP protocol

Workflow of the Http protocol

Client Server (APACHE/NGINX/..../IIS)

0: Original state, no relationship between client and server

Connection: Is the virtual circuit on the network, like QQ, and the server has been connected

1: Establish connection, client sends request, server returns response information along connection

2: Client receives response (HTML code)

3: Disconnect

Format of HTTP request information and response information

GET Request

Request:

1. Request Line

Request Method: Get/post/head/put/delete/trace/options

HEAD and GET are basically the same, just don't return content, such as just to confirm a content such as whether the photo exists, do not need to return, or just detect the state of the server

WEB SERVER may not allow or support these methods, and will return 405:method is not allowed if not supported

Put is used to place resources on the server
Trace: You use the proxy Internet, you want to see if the agent has modified/tampered with your HTTP request, you can use the trace test
Options: Used to see which methods are allowed by the server

Request path: That is, the requested resource, part of the URL

Protocol used: That is, all protocol versions are requested, basically http/1.1

2. Request header information: such as: Host:localhost. Header information and principal information must be preceded by a blank line, even if there is no principal information.

The header information is very rich, and the rich head information is also the learning focus

3. Request principal information (optional)

Response

1. Response lines

Protocol version

Status code: Used to reflect the results of the server response, common

$ OK, the server successfully returned to the page

301/2, Permanent/temporary redirection

304 Not Modified-unmodified, that is, the local cache is taken. (The principle is in the server's response header information, there are last-modified and E-tag, used to flag the service side of the file is modified, then again when the request, the client's request header will have if-modifed-since and if-none-match information, To determine if you need to re-request

307-Redirect to protect the original request data, get no need to use, POST will use

404 Not FOUND, 403 FORBIDDEN, 503 server Internal Error

Status text: Is used to describe the status code, easy to observe

Status code	Defined
1XX Report	Receive the request, continue the process, stay for future expansion
2XX success	The operation was successfully received, understood, and accepted
3xx redirection	Further measures must be taken in order to complete the request
4XX Client Error	The requested syntax is faulty or is not fully satisfied
5XX Server Error	The server cannot complete a clearly valid request

2. Response header information (format Key:value)

Content-length: The length of the next body

3. Response body (may have)

Cases:

http/1.1 OK

Content-type:text/html

Content-length:5

Hello

Q:http protocol must the browser be sent?

A:

POST Request

1. When sending a request using POST, the content-length information must be added to the header information

2. Also need to tell the server content-type:application/x-www-form-urlencoded

Common type See appendix

Text/xml

Application/json

Multipart/form-data

application/x-www-form-urlencoded

PHP + Socket programming to send HTTP requests

Requirements can be simulated download, registration, Login

Appendix HTTP protocol 1 concept and history of the HTTP protocol 1.1 what is the HTTP protocol

The HTTP protocol is the abbreviation for the Hypertext Transfer Protocol (hypertext Transfer Protocol), which is the basis for the World Wide Web ("A worldwide Wide web,www, or a Web"). The HTTP protocol was designed to implement the idea of the Web. The HTTP protocol is located in the application layer of the TCP/IP protocol stack.

The website address that we enter in the address bar of the browser is called the URL (uniformresourcelocator, Uniform Resource Locator). Just like every household has a house address, each page has an Internet address. When you enter a URL in the Address box of the browser or click a hyperlink, the URL determines the address to be browsed. The Web browser uses Hypertext Transfer Protocol (HTTP) to extract the Web page code of the site on the website and renders the Web page required by the client.

The default port used by the HTTP protocol is 80 and also supports custom ports.

1.2 History of the HTTP protocol

The HTTP protocol has undergone a total of 3 versions so far, and the first HTTP protocol was born in March 1989. At that time Berners-lee submitted an article entitled "A Proposal for information management" to CERN (Conseil europeen pour la recherche nucleaire, European Nuclear Energy Institute). The idea of WWW network is put forward in the article, but only in many respects the concept is concerned, but the details are not involved.

The first HTTP protocol version is HTTP 0.9, and its composition is extremely simple, because it only allows the client to send a GET request, which does not contain a protocol header, and each request has only one sentence, for example:

Get/index.html

Because there is no protocol header, the HTTP 0.9 protocol supports only one content, that is, plain text. However, the Web page still supports formatting in HTML language and cannot insert images. So the application that HTTP 0.9 can support is too limited. An HTTP 0.9 transmission first establishes a TCP connection to the Web server by the client, initiates a request by the client, then returns the page content by the Web server, and the connection is closed. If the requested page does not exist, no error code is returned.

The disadvantage of HTTP 0.9 is significant, but at least the first generation of the Web is implemented.

The second version of the HTTP protocol is HTTP 1.0, until HTTP 1.0 becomes the most important transaction-oriented application-layer protocol. The protocol for each request/response is also established and closed once the connection. Its characteristics are simple, easy to manage, so it meets the needs of everyone, has been widely used.

And one of the most significant changes in HTTP 1.0 is the start of supporting clients submitting data to the Web server through the Post method. Since the client and the Web server can no longer only one-way to obtain data, but also to achieve interaction, so CGI (Common Gate Interface, Universal Gateway Interface) began to pop up, the web began to appear on the message Board, forum and other rich applications.

Another notable change in HTTP 1.0 is the ability to support various media types through the HTTP protocol header. From this point on the web, it is no longer just plain text pages, and is more likely to start with HTML tags.

In addition to the new features above, HTTP 1.0 supports long connections (but by default it uses short connections), caching mechanisms, and identity authentication.

Although the design of the HTTP protocol is forward-compatible, many browsers and Web servers now force the HTTP protocol version to be at least 1.0.

The third version of the HTTP protocol is HTTP 1.1, which is the most widely used protocol version of the current one. This version of the HTTP protocol has been stabilized, compared with HTTP 1.0, it added a lot of compelling new features, such as the host protocol header, an HTTP request header can contain a sentence such as:

Host:vimer.cn

From this Web server, you can mount multiple domain names without having to use a separate IP for each domain name, and each site can use a virtual host.

Another new feature of HTTP 1.1 is the support for partial content request/response, which means that when the amount of data requested by the client is large, the request can be made multiple times and each request requires only a portion of the entire piece of data to be fetched. The Web server can also respond in multiple responses, returning only a portion of the entire chunk of data at a time. This allows streaming media to be implemented.

Starting with HTTP 1.1, the client defaults to a long connection to the Web server, which is suitable for rich applications with large amounts of data on the web, resulting in less resource consumption.

Qzhttp is a web Server that supports the HTTP 1.1 protocol.

2.HTTP Protocol Content Introduction

2.1 URI

The HTTP protocol accesses resources through URIs (Uniform Resource Identifiers, Uniform Resource Locators). According to the official definition of RFC 1808, the composition of a complete URI is as follows:

Http://myname:[email protected]: 80/mydir/myfile.html?myvar=myvalue#myfrag

Uri Field

Table 2.1

URI section	Significance
http	Agreement name
MyName	User name (optional)
Mypass	Password (optional)
www.vimer.cn	Host Network Address
80	Port number (optional)
/mydir/myfile.html	Resource Path
Myvar=myvalue	query string (optional)
Myfrag	Anchor Point (optional)

Visible protocol name with "://" End, user name and password with ":" Separated by "@" end, port number and host network address separated by ":", Resource path and query string with "?" Separated, the anchor points begin with #.

Also, only the protocol name, host network address, and resource path must be included in the URI.

A more common example is as follows:

http://www.vimer.cn/

In this case, HTTP is the protocol, www.vimer.cn is the host network address, note that the end of the/is the resource path, which is necessary. When we usually use a Web browser to access, only need to enter www.vimer.cn to access, this is because the Web browser for us to automatically fill in the previous HTTP.//And the last/,web browser to make the request when the URI is still complete, The Web browser does not force the user to enter a URI for the format specification.

2.2 HTTP requests and responses

The interaction of the HTTP protocol consists primarily of the request and response, which refers to the client initiating a message to the Web server requesting the resource, whereas the response is a resource message that the Web server sends back to the client based on the client's request.

The requested message (Request message) is issued with the following sections:

The request line, such as Get/images/logo.gif http/1.1, represents a request logo.gif this file from the/images directory.

L (Request) head, e.g. Accept-language:en

L Blank Line

L Optional Message body

The request line and header must end with <CR><LF> (that is, enter and then wrap). There must be only <CR><LF> in the empty line and no other spaces. In the http/1.1 protocol, all request headers, except host, are optional.

Request method

The http/1.1 protocol defines eight methods (sometimes called "actions") to indicate the different modes of operation of the Request-uri specified resources:

L OPTIONS

Returns the HTTP request methods that the server supports for a specific resource. You can also test the functionality of your server with a request to send a ' * ' to the Web server.

L HEAD

Ask the server for a response that is consistent with the GET request, except that the response body will not be returned. This method allows you to obtain meta information contained in the response message header without having to transmit the entire response content.

L GET

Make a request to a specific resource. Note: The Get method should not be used in operations that produce "side effects", such as in a Web application. One of the reasons is that get can be accessed by web spiders and other casual.

L POST

Submits data to the specified resource for processing requests (such as submitting a form or uploading a file). The data is included in the request body. A POST request may result in the creation of new resources and/or modification of existing resources.

L PUT

Uploads its latest content to the specified resource location.

L DELETE

Deletes the specified resource.

L TRACE

echo the request received by the server.

L CONNECT

The http/1.1 protocol is reserved for proxy servers that can change connections to pipelines.

Method names are case-sensitive. When a request is directed to a resource that does not support the corresponding request method, the server should return the status Code 405 (method not allowed), and the Status Code 501 (not implemented) should be returned when the server does not recognize or support the corresponding request method.

The HTTP server should at least implement the get and head methods, other methods are optional, and an important method in the optional method is post. Of course, all methods that support implementations should conform to the respective semantic definitions of the methods described below. In addition, in addition to the methods described above, a specific HTTP server can also extend a custom method.

Example 2.3 of a GET request is as follows:

Figure 2.3 HTTP Request

GET represents the method name, followed by/representing the resource path, and http/1.1 represents the protocol version. The following are the protocol header sections, and the common header fields are shown in Table 2.2.

HTTP protocol header fields

Table 2.2

Header field	Defined
Accept	The types of media that clients can handle (Mime-type), sorted by priority, and in a comma-delimited list, you can define multiple types and use wildcards
Accept-language	List of natural languages supported by the client
Accept-encoding	List of encodings supported by the client
User-agent	Client Environment type
Host	Server-side host address
Connection	Connection type, default = Keep-alive

The HTTP protocol is a container for Web content. A sample HTTP response of 2.4 is shown:

Figure 2.4 HTTP response

Each response is comprised of an HTTP protocol header and Web content. When the Web server receives a request, it immediately interprets the method used in the request and begins processing the answer. The server's response message also contains the header field as the protocol header. The format of the response is defined in RFC2616 as follows:

status-line*

((General-header) | Response-header | Entity-header) CRLF)

CRLF

[Message-body]

The first line of the response message is the status line (Stauts-line), consisting of the Protocol version and the number status code and the associated text phrase, separated by space characters, except for the last carriage return or line break, in which the carriage return line is not allowed.

Status-line = http-version sp Status-code sp reason-phrase CRLF

The status code is an integer digital that attempts to understand and satisfy the requested three-digit number, the reason phrase (reason-phrase) is to give a textual description of the status code. The status code is used to control the condition, and the reason phrase (reason-phrase) is easy for the user to read. The client does not need to check and display the reason phrase.

The first digit of the status code defines the response type. The latter two digits do not have any classification roles. The first digit has five values, as shown in table 2.3.

HTTP response Status Code

Table 2.3

Status code	Defined
1XX Report	Receive the request, continue the process
2XX success	Steps are successfully received, understood, and accepted
3xx redirection	Further measures must be taken in order to complete the request
4XX Client Error	Requests include the wrong order or cannot be completed
5XX Server Error	The server was unable to complete the apparently valid request

The following is an example of a status code value defined for http/1.1, and a corresponding reason phrase (reason-phrase).

L Client Error

"100″: Continue Continue

"101″: witching Protocols Exchange protocol

L Success

"200″: OK

"201″: Created has been created

"202″: Accepted Receive

"203″: Non-authoritative Information Non-certified information

"204″: no Content

"205″: Reset Content Reset Contents

"206″: Partial content

L redirect

"300″: Multiple Choices multi-channel selection

"301″: Moved permanently permanent transfer

"302″: Found Temporary transfer

"303″: See other

"304″: Not Modified unmodified

"305″: Using proxy for use proxy

"307″: Temporary Redirect

L Client Side Error

' 400″: Bad Request error requests

"401″: Unauthorized not certified

"402″: Payment Required to pay

"403″: Forbidden Forbidden

"404″: Not Found found

"405″: Method not allowed methods not allowed

"406″: Not acceptable does not accept

"407″: Proxy authentication Required need agent authentication

"408″: Request time-out timeout

"409″: Conflict conflict

"410″: Gone failed

"411″: Length Required required Lengths

"412″: Precondition Failed condition failed

"413″: Request entity Too Large requested entities too large

"414″: Request-uri Too Large request URI too long

"415″: Unsupported media type is not supported

"416″: Requested range not satisfiable

"417″: Expectation Failed

L Server Error

"500″: Internal Server error Server internal errors

"501″: Not implemented is not implemented

"502″: Bad Gateway Gateway failed

"503″: Service unavailable

"504″: Gateway time-out gateways Timeout

"505″: HTTP version not supported HTTP versions not supported

The HTTP status code is extensible. The HTTP application does not need to understand the meaning of all registered status codes, although that understanding is clearly advantageous. However, the application must understand the type of the status code specified by the first digit, and any unrecognized response should be considered to be the x00 state of that type, with one exception being that the unrecognized response cannot be cached. For example, if the client receives an unrecognized status code of 431, it can safely assume that the request is wrong, and it treats the response as if it had received a status code of 400. In this case, the user agent should submit the entity and the response together to the user, because the entity is likely to include human-readable information about interpreting the unhealthy state. The message ends with the entity information, which is the content of the resource on the HTTP server that the customer requested.

The Common Content-type

This should be the most common way of POST submission data. The native form form of the browser, and if you do not set the Enctype property, the data will eventually be submitted in application/x-www-form-urlencoded manner. The request is similar to the following (extraneous request headers are omitted in this article):

POST http://www.example.com http/1.1
Content-type:application/x-www-form-urlencoded;charset=utf-8

Title=test&sub%5b%5d=1&sub%5b%5d=2&sub%5b%5d=3
First, Content-type is designated as application/x-www-form-urlencoded, and second, the submitted data is encoded in key1=val1&key2=val2 manner, and both key and Val are URL-transcoded. Most of the service-side languages are very supportive of this approach. For example, in PHP, $_post[' title ' can get to the value of title, $_post[' Sub '] can get a sub array.

Many times, when we use Ajax to submit data, it is also used in this way. For example, the Ajax,content-type default values for JQuery and Qwrap are "application/x-www-form-urlencoded;charset=utf-8".

Multipart/form-data

This is another common way of POST data submission. When we use a form to upload a file, the enctyped of the form must be equal to this value. Look directly at a request example:

POST http://www.example.com http/1.1
Content-type:multipart/form-data; boundary=----Webkitformboundaryrgkcby7qhfd3trwa

------Webkitformboundaryrgkcby7qhfd3trwa
Content-disposition:form-data; Name= "Text"

Title
------Webkitformboundaryrgkcby7qhfd3trwa
Content-disposition:form-data; Name= "File"; Filename= "Chrome.png"
Content-type:image/png

PNG ... content of chrome.png ...
------webkitformboundaryrgkcby7qhfd3trwa--
This example is slightly more complicated. First, a boundary is created to split the different fields, so the boundary is very long and complex in order to avoid repetition with the body content. Then the content-type indicates that the data is encoded in Mutipart/form-data, and what the boundary of this request is. In the message body, the number of fields is divided into several similar parts, each beginning with--boundary, followed by the content description information, followed by a carriage return, and finally the field specific content (text or binary). If you are transferring files, include the file name and file type information. The message body finally ends with a--boundary--mark. For a detailed definition of mutipart/form-data, go to rfc1867 to view it.

This way is generally used to upload files, the major service-side language for it also has a good support.

The two types of POST data mentioned above are natively supported by the browser, and the native form forms are supported in both ways at this stage. But as more and more Web sites, especially WebApp, use Ajax to interact with the data, we can define new ways of submitting data, which will bring more convenience to development.

Application/json

Application/json this content-type as response head everybody certainly is not unfamiliar. In fact, more and more people now use it as a request header to tell the server that the message body is a serialized JSON string. Due to the popularity of the JSON specification, in addition to the low version of IE, the major browsers are natively supported json.stringify, the service-side language has a function of processing JSON, the use of JSON will not encounter any trouble.

The JSON format supports much more complex structured data than key-value pairs, which is also useful. Remember when I was doing a project a few years ago, the level of data that needed to be submitted was very deep, and I was committing the data JSON serialization later. But at the time I was using the JSON string as Val, still in the key-value pair, to be submitted in a x-www-form-urlencoded manner.

The Ajax feature in Google's AngularJS, by default, is to submit a JSON string. For example, the following code:

var data = {' title ': ' Test ', ' Sub ': [N/A]};
$http. Post (URL, data). Success (function (result) {
...
});
The final send request is:

POST http://www.example.com http/1.1
Content-type:application/json;charset=utf-8

{"title": "Test", "Sub": [[i]}
This scheme allows for easy submission of complex structured data, especially for RESTful interfaces. The big grab kits, such as Chrome's own developer tools, Firebug, and Fiddler, will show JSON data in a tree-like structure, very friendly. But there are also some service-side languages that do not support this approach, such as PHP's inability to get content from the above request through the $_post object. At this point, you need to do it yourself: When the Content-type is Application/json in the request header, the original input stream is obtained from the php://input and then json_decode into the object. Some PHP frameworks have already begun to do so.

Of course AngularJS can also be configured to submit data using the X-www-form-urlencoded method. If necessary, you can refer to this article.

Text/xml

My blog mentions xml-rpc (XML Remote Procedure call) before. It is a remote invocation specification that uses HTTP as the transport protocol and XML as the encoding method. The typical XML-RPC request is this:

POST http://www.example.com http/1.1
Content-type:text/xml

<!--? XML version= "1.0"?-->
<methodcall>
<methodname>examples.getStateName</methodname>
<params>
<param>
<value><i4>41</i4></value>

</params>
</methodcall>
XML-RPC protocol is simple, function enough, all kinds of language implementation have. It is also widely used, such as the WordPress Xml-rpc Api, the search engine ping service and so on. In JavaScript, there are also ready-made libraries to support data interaction in this way and to support existing XML-RPC services. However, I personally think that the XML structure is too bloated, the general scenario with JSON will be more flexible and convenient.

Http Protocol Learning notes (Yan 13 teacher)