HTTP protocol message structure

HTTP protocol <2> message structure

HTTP message structure

request message

The structure of the HTTP request message consists of the following parts:

Request Line:
  • The request line contains 请求方法, 目标 URLand 协议版本.
  • They are separated by spaces and terminated by a carriage return line feed (CRLF).

Format: Method SP Request-URI SP HTTP-Version CRLF

Example: GET /index.html HTTP/1.1

Request method
  • GET: Used to obtain (or retrieve) resources from the server.
  1. POST: Used to submit (or send) data to the server, usually used to create new resources.
  2. PUT: Used to replace resources under the specified URL path and can be used to create or update resources.
  3. OPTIONS: used to obtain the request methods supported by the target resource, allowed request headers and other information.
  4. HEAD: Similar to a GET request, but only returns the same response header information as a GET request, without a response body. It is used to obtain metadata of resources.
  5. DELETE: used to delete the specified resource.
  6. TRACE: used to track changes to messages made by the relay server during the request process, often used for debugging and troubleshooting problems.
  7. PATCH: Used to make partial modifications to existing resources and only update part of the resources.

A separate article will be published later to introduce these 8 request methods in detail.

URL

URL is the abbreviation of Uniform Resource Locator, which is used to identify and locate resources on the Internet. A URL consists of multiple parts, including protocol, host name, port number, path, query parameters and fragments, etc.

The following is the general structure of a URL:

[协议]://[主机名或IP地址]:[端口号]/[路径]?[查询参数]#[片段]

The specific explanation is as follows:

  • Protocol: Indicates the communication protocol used on the network, such as HTTP, HTTPS, FTP, etc.
  • Host name or IP address: Specifies the address of the server, which can be a domain name or an IP address.
  • Port number: Optional, specifies the port number that the service on the server listens to. If not specified, the default port number of the protocol is used by default (e.g. HTTP defaults to 80).
  • Path: Specifies the path or folder structure of the resource on the server.
  • Query parameters: Optional, used to pass additional parameters to the server, expressed in the form of key-value pairs, and multiple parameters are separated by "&".
  • Fragment: Optional, representing a specific part of a resource, typically used within a web page to navigate to a specific anchor location.

Here are some example URLs:

  • https://www.example.com/index.html
  • http://192.168.0.1:8080/api/users?sort=asc&page=1
  • ftp://ftp.example.com/files/document.pdf#page=10

URLs can be used to access web pages in a browser, get data from a server, create API requests, etc. By parsing the various parts of the URL, the client is able to accurately locate and request the required resource.

RUL coding will also be explained separately in a separate article later.

Protocol version

This is easy to understand. It is the version number corresponding to HTTP.

Request Headers:
  • The request header contains additional request information in the form of key-value pairs, one line per field, terminated by a carriage return and line feed (CRLF).

Format: Header-Name: Header-Value CRLF

Example:

Host: example.com
User-Agent: Mozilla/5.0
Accept: text/html

Request Headers are additional information sent to the server in an HTTP request to describe the request's attributes, expectations, authentication, etc. Request headers are expressed in name-value format and are located in the header part of the HTTP request.

Here are some common request headers:

  1. User-Agent:
    • Identifies the user agent that initiated the request (i.e. browser, client program, etc.), which is used by the server to identify different user agents.
  2. Accept:
    • Specify the response content type that the client can receive, usually specifying the MIME type (such as text/html, application/json, etc.).
  3. Content-Type:
    • Specifies the media type of the request body content, which is used to tell the server how to parse the request body data.
  4. Authorization:
    • Credential information used for authentication, such as username and password in Basic Authentication.
  5. Cookie:
    • An HTTP cookie sent by the server to the client before being sent in the request to track the user's session state.
  6. Refer:
    • Indicates the source URL of the request, that is, the URL of the previous page. Commonly used to prevent cross-site request forgery (CSRF).
  7. Content-Length:
    • Specifies the length of the request body (in bytes), used to inform the server of the size of the request body.
  8. Cache-Control:
    • Used to control caching behavior, such as indicating whether the response can be cached, cache validity period, etc.
  9. Host:
    • Specify the host name and port number of the target server, which is used by the server to find the corresponding website and process the request.

The above are just some common request headers. In fact, there are more request headers that can be used to pass different information and implement specific functions.

Empty Line:
  • A blank line is used to separate the request headers and request body. It consists of a carriage return and line feed (CRLF) character, indicating the end of the request header.
Request Body:
  • The request body is optional and is used to send additional data to the server in certain situations,

  • The request body is an optional part included in the HTTP request to send data or information to the server. The request body is usually used for request methods such as POST and PUT.

The request body can contain various types of data, such as form data, JSON data, XML data, files, etc. The format and encoding of the data are usually specified by the Content-Type field in the request header.

Here are some examples of common request bodies:

  1. Form Data:
name=John+Doe&[email protected]

name=John+Doe&[email protected]is an example of form data. This is a common way of encoding data into key-value pairs, often used in form submissions or URL query parameters.

In this example, there are two key-value pairs:

  • name=John+DoeIndicates that the key is nameand the value is John+Doe, where +is the URL encoding of spaces.
  • [email protected]Indicates that the key is emailand the value is [email protected].

This form data format is commonly used via HTTP POST requests or added to URLs as query strings. In a practical application, this data can be sent to the server as part of the request body.

  1. JSON data:
{
    
    
  "name": "John Doe",
  "email": "[email protected]"
}

In the request body example, { "name": "John Doe", "email": "[email protected]" }is the JSON data of an example. JSON (JavaScript Object Notation) is a common data exchange format used to represent structured data.

In the example, the entire data is a JSON object, {}surrounded by curly braces. This object contains two properties, namely "name"and "email".

"name": "John Doe"Represents an attribute key-value pair, the attribute name is "name", and the value is "John Doe", indicating the name is "John Doe".

"email": "[email protected]"It also represents an attribute key-value pair. The attribute name is "email"and the value is "[email protected]", indicating that the email is "[email protected]".

JSON is a universal data format used in many scenarios, such as Web API data transmission, configuration files, storage of unstructured data, etc. When working with JSON data, a corresponding parser or library is typically used to read, generate, and parse JSON.

  1. XML data:
<person>
  <name>John Doe</name>
  <email>[email protected]</email>
</person>

<person>Is a root element of XML data that contains related fields or attributes.

<name>John Doe</name>Represents an <name>element containing a name field with the value "John Doe".

<email>[email protected]</email>Represents an <email>element that contains an email field with the value "[email protected]".

XML is the abbreviation of eXtensible Markup Language, which is used to represent structured data. In the request body or response body, you can use XML format to transmit and store data.

XML uses tags to describe the structure and hierarchical relationships of data. <person>, <name>and <email>belong to different tags and are used to define different parts of the data.

For example, you can <person>think of the entire element as a person's information object, which contains a name field and an email field. More fields and data can be added to the XML body according to actual needs.

XML is a universal data representation format used in many scenarios, such as data exchange, configuration files, Web services, etc. When working with XML data, a corresponding parser or library is usually used to read and parse the XML.

  1. File Upload:
------WebKitFormBoundaryABC123
Content-Disposition: form-data; name="file"; filename="example.jpg"
Content-Type: image/jpeg

<binary data>

In the request body example, ------WebKitFormBoundaryABC123it is a form data delimiter used to identify the starting and ending positions of different field data.

Content-Disposition: form-data; name="file"; filename="example.jpg"is metadata used to describe field data, where:

  • form-dataIndicates that this is a form data field.
  • name="file"Indicates that the name of the field is "file".
  • filename="example.jpg"Represents the original file name of the file contained in the field "example.jpg".

Content-Type: image/jpegThe file type contained in the specified field is image/jpeg, that is, the JPEG image file type.

<binary data>Indicates that in the actual request body, binary data should be included here, that is, the actual file content, usually in file upload scenarios.

To actually upload the file, you need to <binary data>replace with the binary content of the file. Typically, these binary data exist in bytes, and the file content can be read as binary through a file read operation and placed in the corresponding part of the request body.

Please note that the content and format of the request body depend on the specific application scenario and requirements. When sending a request, you can set the request body according to your needs and clearly specify the Content-Type field in the request header so that the server can correctly parse and process the request body.

After receiving the request, the server will parse the request body and perform corresponding processing according to the application logic.

response message

状态码HTTP response message is data containing response , 响应头sum and 响应体other information returned by the server to the client after the client sends a request . The following is the general structure of an HTTP response message:

Status Line:

The status line contains 协议版本, 响应状态码and 响应状态messages. For example:

HTTP/1.1 200 OK
Protocol version

Like the protocol version in the request message, they both indicate the version using the http protocol.

Response status code

The response status code is a value in the HTTP response that represents the result of the request processing. It is used to indicate the success, failure, or other special circumstances of the request. Each response status code has specific meaning and semantics.

The HTTP protocol defines a set of standard response status codes. The following are some common response status codes and their meanings:

  • 1xx: information
information describe
100 Continue The server receives only part of the request, but once the server does not reject the request, the client should continue sending the rest of the request.
101 Switching Protocols Server conversion protocol: The server will comply with the client's request and convert it to another protocol.
  • 2xx:success
information describe
200 OK Request successful (followed by response documents to GET and POST requests.)
201 Created The request is created and the new resource is created.
202 Accepted The request for processing was accepted, but processing was not completed.
203 Non-authoritative Information The document has been returned normally, but some response headers may be incorrect because a copy of the document was used.
204 No Content There are no new documents. The browser should continue to display the original document. This status code is useful if the user refreshes the page regularly and the servlet can determine that the user's document is current enough.
205 Reset Content There are no new documents. But the browser should reset what it displays. Used to force the browser to clear form input content.
206 Partial Content The client sends a GET request with a Range header and the server completes it.
  • 3xx: redirect
information describe
300 Multiple Choices Multiple choices. Linked list. Users can select a link to reach their destination. A maximum of five addresses are allowed.
301 Moved Permanently The requested page has been moved to the new url.
302 Found The requested page has been temporarily moved to the new URL.
303 See Other The requested page can be found under another URL.
304 Not Modified The document was not modified as expected. The client has a buffered document and makes a conditional request (usually by providing an If-Modified-Since header to indicate that the client only wants documents that are newer than the specified date). The server tells the client that the original buffered document can continue to be used.
305 Use Proxy Documents requested by the client should be retrieved through the proxy server specified by the Location header.
306 Unused This code was used in a previous version. It is no longer in use, but the code is still retained.
307 Temporary Redirect The requested page has been temporarily moved to a new URL.
  • 4xx: Client error
information describe
400 Bad Request The server failed to understand the request.
401 Unauthorized The requested page requires a username and password.
401.1 Login failed.
401.2 Server configuration causes login failure.
401.3 Authorization is not obtained due to ACL restrictions on resources.
401.4 Filter authorization failed.
401.5 ISAPI/CGI application authorization failed.
401.7 Access is denied by the URL authorization policy on the web server. This error code is specific to IIS 6.0.
402 Payment Required This code is not available yet.
403 Forbidden Access to the requested page is prohibited.
403.1 Execution access is prohibited.
403.2 Read access is prohibited.
403.3 Write access is prohibited.
403.4 SSL required.
403.5 SSL 128 required.
403.6 IP address rejected.
403.7 Requires client certificate.
403.8 Site access denied.
403.9 Too many users.
403.10 Invalid configuration.
403.11 Password change.
403.12 Access to the mapping table is denied.
403.13 The client certificate was revoked.
403.14 Deny directory listing.
403.15 Client access permission exceeded.
403.16 The client certificate is untrusted or invalid.
403.17 The client certificate has expired or is not yet valid.
403.18 The requested URL cannot be executed in the current application pool. This error code is specific to IIS 6.0.
403.19 CGI cannot be performed for clients in this application pool. This error code is specific to IIS 6.0.
403.20 Passport login failed. This error code is specific to IIS 6.0.
404 Not Found 服务器无法找到被请求的页面。
404.0 (无)–没有找到文件或目录。
404.1 无法在所请求的端口上访问Web站点。
404.2 Web服务扩展锁定策略阻止本请求。
404.3 MIME映射策略阻止本请求。
405 Method Not Allowed 请求中指定的方法不被允许。
406 Not Acceptable 服务器生成的响应无法被客户端所接受。
407 Proxy Authentication Required 用户必须首先使用代理服务器进行验证,这样请求才会被处理。
408 Request Timeout 请求超出了服务器的等待时间。
409 Conflict 由于冲突,请求无法被完成。
410 Gone 被请求的页面不可用。
411 Length Required "Content-Length"未被定义。如果无此内容,服务器不会接受请求。
412 Precondition Failed 请求中的前提条件被服务器评估为失败。
413 Request Entity Too Large 由于所请求的实体的太大,服务器不会接受请求。
414 Request-url Too Long 由于url太长,服务器不会接受请求。当post请求被转换为带有很长的查询信息的get请求时,就会发生这种情况。
415 Unsupported Media Type 由于媒介类型不被支持,服务器不会接受请求。
416 Requested Range Not Satisfiable 服务器不能满足客户在请求中指定的Range头。
417 Expectation Failed 执行失败。
423 锁定的错误。

5xx:服务器错误

消息 描述
500 Internal Server Error 请求未完成。服务器遇到不可预知的情况。
500.12 应用程序正忙于在Web服务器上重新启动。
500.13 Web服务器太忙。
500.15 不允许直接请求Global.asa。
500.16 UNC授权凭据不正确。这个错误代码为IIS 6.0所专用。
500.18 URL授权存储不能打开。这个错误代码为IIS 6.0所专用。
500.100 内部ASP错误。
501 Not Implemented 请求未完成。服务器不支持所请求的功能。
502 Bad Gateway 请求未完成。服务器从上游服务器收到一个无效的响应。
502.1 CGI应用程序超时。
502.2 CGI应用程序出错。
503 Service Unavailable 请求未完成。服务器临时过载或宕机。
504 Gateway Timeout 网关超时。
505 HTTP Version Not Supported 服务器不支持请求中指明的HTTP版本。

一般常用的状态码

  • 200 OK:请求成功,服务器成功处理了请求并返回响应。
  • 201 Created:请求成功,服务器成功处理请求并创建了新资源。
  • 400 Bad Request:请求无效,服务器无法理解或处理请求。
  • 401 Unauthorized:未授权,请求要求身份验证。
  • 403 Forbidden:禁止访问,服务器拒绝请求的访问权限。
  • 404 Not Found:资源不存在,请求的资源无法找到。
  • 500 Internal Server Error:服务器内部错误,通常是服务器在处理请求时发生了错误。
  • 503 Service Unavailable:服务不可用,服务器当前无法处理请求,可能因为过载或维护等原因。
响应状态

响应状态是指HTTP响应中的状态行,它包含了HTTP版本、响应状态码和响应状态消息。状态行有如下的一般结构:

HTTP/1.1 200 OK

具体解释如下:

  • HTTP/1.1:表示所使用的HTTP协议版本。
  • 200:表示响应状态码,指示请求成功。
  • OK:表示响应状态消息,提供关于响应状态码的简短描述。

响应状态码用于指示服务器对请求的处理结果,响应状态消息则为状态码提供一些解释性的描述。

HTTP协议定义了一组标准的响应状态码(例如,200、404、500等),每个状态码都有特定的含义和语义。

通过查看响应的状态码和状态消息,客户端可以了解请求的处理结果和服务器返回的状态信息,以便采取相应的处理措施。

响应头(Response Headers):

响应头包含响应报文的各种元数据信息。每行一个头部字段。

响应头(Response Headers)是HTTP响应中包含的元数据信息,用于提供关于响应的附加信息和配置参数。响应头以名称-值的形式表示,并位于HTTP响应的头部部分。

以下是一些常见的响应头:

  1. Content-Type:指示响应主体的媒体类型,例如text/html、application/json等。

  2. Content-Length:指示响应主体的长度(以字节为单位)。

  3. Server:指示服务器的软件名称和版本。

  4. Date:指示响应的日期和时间。

  5. Cache-Control:用于控制缓存行为,例如指示是否可以缓存响应、缓存有效期等。

  6. Set-Cookie:向客户端设置一个HTTP Cookie。

  7. Location:指示客户端重定向到的URL。

  8. Expires:指示响应的过期时间。

  9. Etag:用于标识资源的特定版本。

这只是一小部分常见的响应头,实际上还有许多其他的响应头可以用于传递不同的信息和配置。

响应头提供了关于响应的重要信息,客户端可以根据响应头做出相应的处理。例如,根据Content-Type确定如何解析和处理响应主体的内容,根据Cache-Control确定是否从缓存中获取响应等。

空行(Blank Line):

空行用于分隔头部和响应体,由一个回车换行符组成。

响应体(Response Body):

响应体包含服务器返回的实际数据。响应体的内容根据Content-Type指定的媒体类型而定。例如,对于HTML内容,响应体可能包含HTML标记的文本或网页;对于JSON内容,响应体可能包含JSON格式的数据。

以下是一个示例的HTTP响应报文:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1024
Cache-Control: no-cache

<!DOCTYPE html>
<html>
<head>
    <title>Example</title>
</head>
<body>
    <h1>Hello, World!</h1>
</body>
</html>

在实际的开发中,通过解析HTTP响应报文,可以获取服务器返回的状态码、头部信息和响应体数据,并根据需要进行处理。

Guess you like

Origin blog.csdn.net/weixin_44369049/article/details/132154276