Front End Learning HTTP Message Series first--Start line

Previous words

If HTTP is the messenger of the Internet, then the HTTP message is the parcel that it uses to carry things. HTTP messages are simple, formatted chunks of data sent between HTTP applications, each containing a request from the client, or a response from the server. They consist of three parts: the starting line, the header, and the body part of the entity. This article is the first article of the HTTP Message series--The Starting line

Message Syntax

All HTTP messages can be divided into two categories: Request message and Response message (response message). The request message requests an action from the Web server, and the response message returns the result of the request to the client. The basic message structure of the request and response message is the same

Format of Request message:

<method> <request-URL> <version>
Format of the response message:
<version><status><reason-phrase>
"Method"
The action that the client wants the server to perform on the resource. is a single word, such as, or post
"Request URL (Request-url)"
Name the requested resource, or the full URL of the URL path component
"Version"
The HTTP version used by the message, in the following format:
Http/<major>.<minor>
Where major version number (major) and minor version number (minor) are integers
"Status code (Status-code)"
These three-digit numbers describe what happened during the request. The first digit of each status code is used to describe the general category of State ("Success", "error", etc.)
"Reason phrase (reason-phrase)"
A readable version of the numeric status code that contains all the text before the line termination sequence
"Header"
can have 0 or more headers, each header contains a name, followed by a colon (:), then an optional space, followed by a value, and finally a CRLF. The header is terminated by a blank line (CRLF), indicating the end of the header list and the beginning of the entity body part.
"Body part of an entity (Entity-body)"
The body part of an entity contains a block of data that consists of arbitrary data. Not all messages contain the body part of the entity, and sometimes the message ends with a CRLF
Classification
All HTTP messages start with a starting line. The starting line of the request message shows what to do, and the starting line of the response message indicates what happened. The contents of the starting line are described in more detail below
Request Line
Request a message request the server to do some operations on the resource. The starting line of the request message, or called the request line, contains a method and a request URL that describes what the server should do, and the request URL describes which resource to execute the method on. The request line also contains the version of HTTP, which tells the server what kind of HTTP the client is using. All these fields are delimited by whitespace
Response Line
The response message carries the status information and all the result data generated by the operation and returns it to the client. The starting line of the response message, or the response line, contains the HTTP version used for the response message, the number status code, and a reason phrase that describes the text form of the operation status. All of these fields are delimited by whitespace
Method
The starting line of the request starts with a method that tells the server what to do
There are 8 common methods of http:
Get: Get resource post: Transfer entity body put: Transfer file head: Get message header Delete: Delete file options: Ask for Supported methods trace: Trace path connect: Requires tunneling protocol to connect proxy
GET
Get is the most common method. Typically used to request that a server send a resource
HEAD
The head method is similar to the behavior of the Get method, but the server returns only the header in the response. The body part of the entity is not returned. This allows the client to conduct a survey of the resource's header without acquiring the actual resources. Using head, you can: 1, to understand the situation of the resource without obtaining the resources (for example, to determine its type); 2. Examine the status code in the response to see if an object exists; 3. Examine the header to see if the resource has been modified.
PUT
Instead of reading the document from the server, the Put method writes the document to the server. Just like the FTP protocol file upload, it requires that the contents of the file be included in the body of the request message, and then saved to the location specified by the request URI
However, because the http/1.1 put method itself does not have a validation mechanism, anyone can upload files, there is a security issue, so the general Web site does not use this method. If you are cooperating with the validation mechanism of the Web application, or if the architecture design uses the rest (representational state Transfer, representational status transfer) standard
Similar web sites, you may be able to use the Put method
POST
The Post method was originally used to enter data into the server. In fact, it is usually used to support HTML forms
TRACE
A trace request initiates a "loopback" diagnostic on the destination server side. The server at the last stop of the trip bounces back a trace response and carries the original request message it received in the response body. This allows the client to look at the request/response chain consisting of all intermediate HTTP applications, whether the original message has been destroyed or modified.
When sending a request, fill in the number in the Max-forwards header field, minus 1 on each server side, and stop the transmission when the value is just down to 0 o'clock, and the last server that receives the request returns the response of the status code OK
However, the trace method is not often used, plus it is prone to trigger xst (Cross-site tracing, cross-site tracking) attacks, and usually less
OPTIONS
The options method requests the Web server to inform it of the various features it supports. You can ask what methods the server typically supports, or which methods are supported for certain special resources
This provides a means for client applications to determine the optimal way to access various resources without actually accessing those resources
DELETE
What the Delete method does is ask the server to delete the resource specified by the request URL
However, the http/1.1 Delete method itself, like the PUT method, does not have a validation mechanism, so the general Web site does not use the Delete method. It is still possible to use the Web application's validation mechanism or to comply with the rest standard
CONNECT
The Connect method requires a tunnel to be established when communicating with a proxy server to enable TCP communication with the tunneling protocol. The main use of SSL (secure Sockets layers, Secure Sockets Layer) and TLS (Transport layer Security, Transport Layer Secure) protocol to encrypt the communication after the network tunnel transmission
Extension methods
HTTP is designed to be extensible in fields so that the new features don't invalidate old software. The extension method refers to a method that is not defined in the http/1.1 specification. The server implements some HTTP services for the resources it manages, and these methods provide a means for developers to extend these HTTP service capabilities. The methods listed in the following table are all the methods that the WebDAV HTTP extension contains to help publish Web content to a Web server over HTTP
Version
There are several versions of the HTTP protocol used now. HTTP applications should be as robust as possible to handle a variety of different HTTP protocol variants. The version that is still in use is as follows
"http/0.9"
The 1991 prototype version of HTTP is called http/0.9. This protocol has a number of serious design flaws that should only be used to interact with the old client. http/0.9 supports only get methods, does not support MIME types for multimedia content, various HTTP headers, or version numbers. The http/0.9 definition was originally designed to get a simple HTML object, and it was quickly replaced by h1tp/1.0.
"Http/1.0"
1.0 is the first HTTP version to be widely used. Http/1.0 adds a version number, various HTTP headers, some extra methods, and the processing of multimedia objects, making it possible for Web pages and interactive forms to contain vivid images that make the World Wide Web widely accepted. This specification has never been well described. The business evolution and academic research of this HTTP protocol are in the fast-progressing era, and it is a collection of best practices
"Http/1.0"
In the the mid 1990s leaves, many popular web clients and servers are rapidly adding features to HTTP to meet the needs of a rapidly expanding and commercially successful world Wide Web. Many of these features, including persistent keep-alive connections, virtual host support, and proxy connection support, have been added to the HTTP and become an unofficial fact standard. This unofficial version of HTTP extensions is often referred to as http/1.0+
"http/1.1"
http/1.1 focuses on correcting structural flaws in HTTP design, clarifying semantics, introducing important performance optimization measures, and removing some bad features. http/1.1 also includes support for more complex web applications and deployment methods. http/1.1 is the HTTP version currently in use
"Http-ng (aka http/2.0)"
Http-ng is a prototype recommendation for the successor structure of http/1.1, and it focuses on the performance optimization and the more powerful remote execution framework for service logic. Further reduces network latency on the basis of full semantic compatibility with http/1.1
With the release of the official version of the HTTP/2 agreement on May 14, 2015, more and more websites and third-party CDN services are starting to enable HTTP/2. HTTP/2 is the next generation of HTTP and the future of HTTP.
Status code
The HTTP status code is responsible for the return result of the client HTTP request, the marking of the server-side processing is normal, the notification error, and so on. HTTP status codes are divided into five categories, with different types representing different categories of status codes
1XX Informational (Informational status code) indicates that the received request is processing a 2XX Success (Success status code) indicates that the request is processed correctly 3XX redirection (redirected status code) indicates that additional action is required to complete the request 4XX Client Error (Client error status code) indicates that the server could not process the request 5XX Server error (server fault status code) indicating that the server is processing the request error
As long as you follow the definition of the status Code category, even if you change the status code defined in the RFC2616, or the server side creates the status code itself.
There are 40 HTTP status codes recorded on RFC2616, plus WebDAV (web-based distributed Authoring and Versioning, Distributed Authoring and versioning based on the World Wide Web) (RFC4918, 5842 ) and additional HTTP status code (RFC6585), and more than 60 kinds of extensions. But in fact, there are only about more than 10 kinds of it.
"1XX"
"2XX"
These requests are usually successful when the client initiates the request. The server has a set of status codes that are used to indicate success, corresponding to different types of requests
"3XX"
The redirect status code either tells the client to use an alternate location to access the resource that they are interested in, or it provides an alternative response instead of the content of the resource. If the resource has been moved, you can send a redirect status code and an optional location header to tell the client that the resource has been moved and where it can now be found. This allows the browser to transparently transfer to a new location without disturbing the user.
"4XX"
Sometimes the client sends something that the server cannot handle, such as a malformed request message, or, most commonly, a URL that does not exist.
We've all seen the infamous 404 Not Found error code while browsing the web-just as the server tells us that it knows nothing about the resources we request. Many client-side errors are handled by the browser. Only a small number of errors, such as 404, will pass through the browser to the user
"5XX"
Sometimes the client sends a valid request, and the server itself has an error. This may be because the client encountered a defect in the server, or a child element on the server, such as a gateway resource, went wrong. A problem often occurs when an agent tries to communicate with the server on behalf of the client. The agent publishes a 5XX server error status code to describe the problem encountered
Front End Learning HTTP Message Series first--Start line