HTTP协议快速指南

HTTP - 概述


超文本传输​​协议 (HTTP) 是分布式、协作、超媒体信息系统的应用层协议。这是自 1990 年以来万维网（即互联网）数据通信的基础。HTTP 是一种通用的无状态协议，可用于其他目的，也可以使用其请求方法、错误代码和标头的扩展。

基本上，HTTP 是一种基于 TCP/IP 的通信协议，用于在万维网上传递数据（HTML 文件、图像文件、查询结果等）。默认端口是 TCP 80，但也可以使用其他端口。它为计算机之间的通信提供了一种标准化的方式。HTTP 规范指定了客户端如何构造请求数据并将其发送到服务器，以及服务器如何响应这些请求。

基本功能

以下三个基本特性使 HTTP 成为一个简单而强大的协议：

  • HTTP 是无连接的：HTTP 客户端，即。浏览器发起 HTTP 请求，请求发出后，客户端断开与服务器的连接并等待响应。服务器处理请求并重新建立与客户端的连接以发回响应。

  • HTTP 是独立于媒体的：这意味着，只要客户端和服务器都知道如何处理数据内容，任何类型的数据都可以通过 HTTP 发送。这是客户端和服务器使用适当的 MIME 类型指定内容类型所必需的。

  • HTTP 是无状态的：如上所述，HTTP 是无连接的，这是 HTTP 是无状态协议的直接结果。服务器和客户端仅在当前请求期间才知道彼此。之后，两个人都忘记了对方。由于协议的这种性质，客户端和浏览器都不能保留跨网页的不同请求之间的信息。

HTTP/1.0 为每个请求/响应交换使用一个新连接，而 HTTP/1.1 连接可用于一个或多个请求/响应交换。

基本架构

下图显示了 Web 应用程序的一个非常基本的架构，并描述了 HTTP 所在的位置：

HTTP 架构

HTTP 协议是基于客户端/服务器架构的请求/响应协议，其中 Web 浏览器、机器人和搜索引擎等充当 HTTP 客户端，Web 服务器充当服务器。

客户端

HTTP 客户端以请求方法、URI 和协议版本的形式向服务器发送请求，然后是一个类似于 MIME 的消息，其中包含请求修饰符、客户端信息和通过 TCP/IP 连接的可能的正文内容。

服务器

HTTP 服务器以状态行进行响应，包括消息的协议版本和成功或错误代码，然后是类似于 MIME 的消息，其中包含服务器信息、实体元信息和可能的实体主体内容。

HTTP - 参数

本章将列出一些重要的 HTTP 协议参数及其在通信中使用的语法。例如，日期格式、URL 格式等。这将帮助您在编写 HTTP 客户端或服务器程序时构建请求和响应消息。您将在后续章节中看到这些参数的完整用法，同时解释 HTTP 请求和响应的消息结构。

HTTP 版本

HTTP 使用<major>.<minor>编号方案来指示协议的版本。HTTP 消息的版本由第一行中的 HTTP-Version 字段指示。以下是指定 HTTP 版本号的一般语法：

HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT

例子

HTTP/1.0

or

HTTP/1.1

统一资源标识符 (URI)

统一资源标识符 (URI) 是简单格式化的、不区分大小写的字符串，包含名称、位置等来标识资源，例如网站、Web 服务等。用于 HTTP 的 URI 的一般语法如下：

URI = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

此处如果port为空或未给出，则假定端口 80 用于 HTTP，空的abs_path等效于"/" 的abs_path。保留和不安全集中的字符以外的字符等效于它们的“”％“HEX HEX”编码。

例子

以下两个 URI 是等效的：

http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html

日期/时间格式

所有 HTTP 日期/时间戳必须以格林威治标准时间 (GMT) 表示，无一例外。HTTP 应用程序可以使用以下三种日期/时间戳表示中的任何一种：

Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format

字符集

您使用字符集来指定客户端喜欢的字符集。可以列出多个字符集，用逗号分隔。如果未指定值，则默认为 US-ASCII。

例子

以下是有效的字符集：

US-ASCII

or

ISO-8859-1

or 

ISO-8859-7

内容编码

内容编码值表示在通过网络传递内容之前已使用编码算法对内容进行编码。内容编码主要用于允许在不丢失身份的情况下压缩或以其他方式有效地转换文档。

所有内容编码值都不区分大小写。HTTP/1.1 在 Accept-Encoding 和 Content-Encoding 标头字段中使用内容编码值，我们将在后续章节中看到。

例子

以下是有效的编码方案：

Accept-encoding: gzip

or

Accept-encoding: compress

or 

Accept-encoding: deflate

媒体类型

HTTP 在Content-Type和Accept标头字段中使用 Internet 媒体类型，以提供开放和可扩展的数据类型和类型协商。所有媒体类型值都在 Internet 号码分配机构 ((IANA) 注册。以下是指定媒体类型的通用语法：

media-type     = type "/" subtype *( ";" parameter )

类型、子类型和参数属性名称不区分大小写。

例子

Accept: image/gif

语言标签

HTTP 在Accept-Language和Content-Language字段中使用语言标签。语言标签由 1 个或多个部分组成： 主要语言标签和可能为空的子标签系列：

language-tag  = primary-tag *( "-" subtag )

标签中不允许有空格，并且所有标签都不区分大小写。

例子

示例标签包括：

 en, en-US, en-cockney, i-cherokee, x-pig-latin

其中任何两个字母的主标签是 ISO-639 语言缩写，任何两个字母的初始子标签都是 ISO-3166 国家代码。

HTTP - 消息

HTTP 基于客户端-服务器架构模型和无状态请求/响应协议，通过可靠的 TCP/IP 连接交换消息来运行。

HTTP“客户端”是一个程序（Web 浏览器或任何其他客户端），它建立与服务器的连接以发送一个或多个 HTTP 请求消息。HTTP“服务器”是一个程序（通常是 Web 服务器，如 Apache Web 服务器或 Internet 信息服务 IIS 等），它接受连接以便通过发送 HTTP 响应消息来服务 HTTP 请求。

HTTP 使用统一资源标识符 (URI) 来识别给定资源并建立连接。一旦建立连接，HTTP 消息就会以类似于 Internet 邮件 [RFC5322] 和多用途 Internet 邮件扩展 (MIME) [RFC2045] 使用的格式传递。这些消息由客户端到服务器的请求和服务器到客户端的响应组成，格式如下：

 HTTP-message   = <Request> | <Response> ; HTTP/1.1 messages

HTTP 请求和 HTTP 响应使用 RFC 822 的通用消息格式来传输所需的数据。这种通用消息格式由以下四项组成。

    

  • A Start-line
    • 

  • Zero or more header fields followed by CRLF
    • 

  • An empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields
    • 

  • Optionally a message-body
    •

以下部分将解释 HTTP 消息中使用的每个实体。

消息起始行

起始行将具有以下通用语法：

start-line = Request-Line | Status-Line

我们将在分别讨论 HTTP 请求和 HTTP 响应消息时讨论请求行和状态行。现在让我们看一下请求和响应情况下的起始行示例：

GET /hello.htm HTTP/1.1     (This is Request-Line sent by the client)

HTTP/1.1 200 OK             (This is Status-Line sent by the server)

标头字段

HTTP 标头字段提供有关请求或响应或消息正文中发送的对象的必需信息。HTTP 消息头有以下四种类型：

  • 一般标头：这些头域对请求和响应消息都通用。

  • 请求标头：这些标头字段仅适用于请求消息。

  • 响应标头：这些头域只适用于响应消息。

  • 实体标头：这些标头字段定义有关实体主体的元信息，或者，如果没有主体存在

上面提到的所有标题都遵循相同的通用格式，每个标题字段都由一个名称后跟一个冒号 (:)和字段值组成，如下所示：

message-header = field-name ":" [ field-value ]

以下是各种标头字段的示例：

User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com
Accept-Language: en, mi
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain

消息体

消息正文部分对于 HTTP 消息是可选的，但如果它可用，则它用于携带与请求或响应关联的实体主体。如果实体主体是关联的，那么通常Content-Type和Content-Length标题行指定关联主体的性质。

消息体是承载实际HTTP请求数据（包括表单数据和上传等）和来自服务器的HTTP响应数据（包括文件、图像等）的消息体。以下是消息正文的简单内容：

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

HTTP - 请求

HTTP 客户端以请求消息的形式向服务器发送 HTTP 请求，请求消息包括以下格式：

    

  • A Request-line
    • 

  • Zero or more header (General|Request|Entity) fields followed by CRLF
    • 

  • An empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields
    • 

  • Optionally a message-body
    •

以下部分将解释 HTTP 消息中使用的每个实体。

消息请求行

Request-Line 以方法标记开始，接着是 Request-URI 和协议版本，并以 CRLF 结束。元素由空格 SP 字符分隔。

Request-Line   = Method SP Request-URI SP HTTP-Version CRLF

让我们讨论一下 Request-Line 中提到的每个部分。

请求方法

请求 方法 指示要对给定Request-URI标识的资源执行的方法。该方法区分大小写，应始终以大写形式提及。以下是 HTTP/1.1 中支持的方法

序列号方法及说明
1GET
GET 方法用于使用给定的 URI 从给定的服务器检索信息。使用 GET 的请求应该只检索数据，并且对数据没有其他影响。
2HEAD
与 GET 相同，但仅传输状态行和标题部分。
3POST
POST 请求用于向服务器发送数据，例如使用 HTML 表单的客户信息、文件上传等。
4PUT
用上传的内容替换目标资源的所有当前表示。
5DELETE
删除 URI 给出的目标资源的所有当前表示。
6CONNECT
建立到由给定 URI 标识的服务器的隧道。
7OPTIONS
描述目标资源的通信选项。
8TRACE
沿着到目标资源的路径执行消息环回测试。

请求-URI

Request-URI 是一个统一资源标识符，用于标识应用请求的资源。以下是指定 URI 的最常用形式：

Request-URI = "*" | absoluteURI | abs_path | authority
序列号方法及说明
1星号*用于 HTTP 请求不适用于特定资源，但适用于服务器本身，并且仅在使用的方法不一定适用于资源时才允许使用。例如：

OPTIONS * HTTP/1.1

2absoluteURI在向代理发出 HTTP 请求时使用。请求代理从有效缓存中转发请求或为其提供服务，并返回响应。例如：

GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1

3Request-URI 最常见的形式是用于标识源服务器或网关上的资源。例如，希望直接从源服务器检索上述资源的客户端将创建到主机“www.w3.org”的端口 80 的 TCP 连接并发送以下行：

GET /pub/WWW/TheProject.html HTTP/1.1
Host：www.w3.org

注意绝对路径不能为空；如果原始 URI 中不存在任何内容，则必须以“/”（服务器根目录）的形式给出

请求标头字段

当我们学习 HTTP 头字段时，我们将在单独的章节中学习 一般标头和 实体标头。现在让我们检查一下什么是请求标头字段。

请求头字段允许客户端将有关请求以及客户端本身的附加信息传递给服务器。这些字段充当请求修饰符，并且可以根据要求使用以下重要的请求标头字段。

  • Accept-Charset

  • Accept-Encoding

  • Accept-Language

  • Authorization

  • Expect

  • From

  • Host

  • If-Match

  • If-Modified-Since

  • If-None-Match

  • If-Range

  • If-Unmodified-Since

  • Max-Forwards

  • Proxy-Authorization

  • Range

  • Referer

  • TE

  • User-Agent

如果您要编写自己的自定义客户端和 Web 服务器，您可以引入自定义字段。

请求消息示例

现在让我们把它们放在一起形成一个 HTTP 请求，从 tutorialspoint.com 上运行的 Web 服务器获取hello.htm页面

GET /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

这里我们没有向服务器发送任何请求数据，因为我们正在从服务器获取计划 HTML 页面。Connection 是这里使用的通用标头，其余标头是请求标头。以下是我们使用请求消息正文向服务器发送表单数据的另一个示例：

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: application/x-www-form-urlencoded
Content-Length: length
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

licenseID=string&content=string&/paramsXML=string

这里给定的 URL /cgi-bin/process.cgi将用于处理传递的数据，因此将重新调整响应。这里的 content-type告诉服务器传递的数据是简单的 Web 表单数据，length将是放入消息正文中的数据的实际长度。以下示例显示了如何将计划 XML 传递到 Web 服务器：

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: text/xml; charset=utf-8
Content-Length: length
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

<?xml version="1.0" encoding="utf-8"?>
<string xmlns="http://clearforest.com/">string</string>

HTTP - 响应

在接收并解释请求消息后，服务器以 HTTP 响应消息进行响应：

    

  • A Status-line
    • 

  • Zero or more header (General|Response|Entity) fields followed by CRLF
    • 

  • An empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields
    • 

  • Optionally a message-body
    •

以下部分将解释 HTTP 消息中使用的每个实体。

消息状态行

状态行由协议版本后跟数字状态代码及其相关文本短语组成。元素由空格 SP 字符分隔。

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

让我们讨论状态行中提到的每个部分。

HTTP 版本

支持 HTTP 版本 1.1 的服务器将返回以下版本信息：

HTTP-Version = HTTP/1.1

状态码

Status-Code 元素是一个 3 位整数，其中 Status-Code 的第一个数字定义响应的类别，最后两个数字没有任何分类作用。第一个数字有 5 个值：

序列号代码和说明
11xx：信息
这意味着收到请求并继续处理。
22xx：成功
这意味着操作已成功接收、理解和接受。
33xx：重定向
这意味着必须采取进一步的措施才能完成请求。
44xx：客户端错误
这意味着请求包含错误的语法或无法完成
55xx: 服务器错误
服务器未能完成一个明显有效的请求

HTTP 状态码是可扩展的，并且 HTTP 应用程序不需要理解所有注册状态码的含义。所有状态代码的列表已在单独的章节中提供，供您参考。

响应头字段

当我们学习 HTTP 头字段时，我们将在单独的章节中学习 一般标头和实体标头。现在让我们检查一下什么是响应头字段。

响应标头 字段允许服务器传递有关无法放置在状态行中的响应的附加信息。这些标头字段提供有关服务器的信息以及有关对由 Request-URI 标识的资源的进一步访问的信息。

  • Accept-Ranges

  • Age

  • ETag

  • Location

  • Proxy-Authenticate

  • Retry-After

  • Server

  • Vary

  • WWW-Authenticate

如果您要编写自己的自定义 Web 客户端和服务器，您可以引入自定义字段。

响应消息示例

现在让我们把它们放在一起形成一个 HTTP 响应，请求从 tutorialspoint.com 上运行的 Web 服务器获取hello.htm页面

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

以下是 Web 服务器找不到请求页面时显示错误情况的 HTTP 响应消息示例：

HTTP/1.1 404 Not Found
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Connection: Closed
Content-Type: text/html; charset=iso-8859-1
   
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
   <title>404 Not Found</title>
</head>
<body>
   <h1>Not Found</h1>
   <p>The requested URL /t.html was not found on this server.</p>
</body>
</html>

以下是当 Web 服务器在给定的 HTTP 请求中遇到错误的 HTTP 版本时显示错误情况的 HTTP 响应消息示例：

HTTP/1.1 400 Bad Request
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Content-Type: text/html; charset=iso-8859-1
Connection: Closed
   
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
   <title>400 Bad Request</title>
</head>
<body>
   <h1>Bad Request</h1>
   <p>Your browser sent a request that this server could not understand.<p>
   <p>The request line contained invalid characters following the protocol string.<p>
</body>
</html>

HTTP - 方法

HTTP/1.1 的常用方法集定义如下，可根据需要进行扩展。这些方法名称区分大小写，并且必须以大写形式使用。

序列号方法及说明
1GET
GET 方法用于使用给定的 URI 从给定的服务器检索信息。使用 GET 的请求应该只检索数据，并且对数据没有其他影响。
2HEAD
与 GET 相同，但仅传输状态行和标题部分。
3POST
POST 请求用于向服务器发送数据，例如使用 HTML 表单的客户信息、文件上传等。
4PUT
用上传的内容替换目标资源的所有当前表示。
5DELETE
删除 URI 给出的目标资源的所有当前表示。
6CONNECT
建立到由给定 URI 标识的服务器的隧道。
7OPTIONS
描述目标资源的通信选项。
8TRACE
沿着到目标资源的路径执行消息环回测试。

GET方法

GET 请求通过在请求的 URL 部分中指定参数来从 Web 服务器检索数据。这是用于文档检索的主要方法。下面是一个使用 GET 方法获取 hello.htm 的简单示例：

GET /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

服务器对上述 GET 请求的响应如下：

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

HEAD方法

HEAD 方法在功能上类似于 GET，不同之处在于服务器使用响应行和标题进行回复，但没有实体主体。下面是一个使用 HEAD 方法获取 hello.htm 头信息的简单示例：

HEAD /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

以下将是针对上述 GET 请求的服务器响应：

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed

您可以注意到这里的服务器在标头之后没有发送任何数据。

POST 方法

当您想向服务器发送一些数据时使用 POST 方法，例如文件更新、表单数据等。下面是一个简单的示例，它使用 POST 方法将表单数据发送到服务器，该数据将由服务器处理process.cgi 最后会返回一个响应：

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: text/xml; charset=utf-8
Content-Length: 88
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

<?xml version="1.0" encoding="utf-8"?>
<string xmlns="http://clearforest.com/">string</string>

服务器端脚本 process.cgi 处理传递的数据并发送以下响应：

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Request Processed Successfully</h1>
</body>
</html>

PUT方法

PUT 方法用于请求服务器将包含的实体主体存储在给定 URL 指定的位置。以下示例请求服务器将给定的实体主体保存在服务器根目录的hello.htm中：

PUT /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Connection: Keep-Alive
Content-type: text/html
Content-Length: 182

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

服务器会将给定的实体主体存储在hello.htm文件中，并将以下响应发送回客户端：

HTTP/1.1 201 Created
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-type: text/html
Content-length: 30
Connection: Closed

<html>
<body>
<h1>The file was created.</h1>
</body>
</html>

DELETE方法

DELETE 方法用于请求服务器删除给定 URL 指定位置的文件。以下示例请求服务器删除服务器根目录下的给定文件hello.htm ：

DELETE /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Connection: Keep-Alive

服务器将删除提到的文件hello.htm并将以下响应发送回客户端：

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-type: text/html
Content-length: 30
Connection: Closed

<html>
<body>
<h1>URL deleted.</h1>
</body>
</html>

CONNECT方法

客户端使用 CONNECT 方法通过 HTTP 与 Web 服务器建立网络连接。以下示例请求与在主机 tutorialspoint.com 上运行的 Web 服务器建立连接：

CONNECT www.tutorialspoint.com HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

与服务器建立连接，并将以下响应发送回客户端：

HTTP/1.1 200 Connection established
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)

OPTIONS方法

客户端使用 OPTIONS 方法来找出 Web 服务器支持的 HTTP 方法和其他选项。客户端可以为 OPTIONS 方法指定一个 URL，或者一个星号 (*) 来引用整个服务器。以下示例请求在 tutorialspoint.com 上运行的 Web 服务器支持的方法列表：

OPTIONS * HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

服务器会根据服务器当前的配置发送信息，例如：

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Allow: GET,HEAD,POST,OPTIONS,TRACE
Content-Type: httpd/unix-directory

TRACE方法

TRACE 方法用于将每个 HTTP 请求的内容返回给请求者，在开发时可用于调试目的。以下示例显示了 TRACE 方法的用法：

TRACE / HTTP/1.1
Host: www.tutorialspoint.com
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

服务器将响应上述请求发送以下消息：

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-Type: message/http
Content-Length: 39
Connection: Closed

TRACE / HTTP/1.1
Host: www.tutorialspoint.com
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

HTTP - 状态码

服务器响应中的 Status-Code 元素是一个 3 位整数，其中 Status-Code 的第一个数字定义响应的类别，最后两个数字没有任何分类作用。第一个数字有 5 个值：

序列号代码和说明
11xx：信息
这意味着收到请求并继续处理。
22xx：成功
这意味着操作已成功接收、理解和接受。
33xx：重定向
这意味着必须采取进一步的措施才能完成请求。
44xx：客户端错误
这意味着请求包含错误的语法或无法完成
55xx: 服务器错误
服务器未能完成一个明显有效的请求

HTTP 状态码是可扩展的，并且 HTTP 应用程序不需要理解所有注册状态码的含义。以下是所有状态代码的列表。

1xx：信息

信息： 描述：
100 继续 服务器只收到了部分请求，但只要没有被拒绝，客户端就应该继续请求
101 切换协议 服务器切换协议

2xx：成功

信息： 描述：
200 OK 请求正常
201 已创建 请求完成，创建新资源 
202 接受 请求被接受处理，但处理未完成
203 非权威信息 实体标头中的信息来自本地或第三方副本，而不是来自原始服务器。
204 无内容 响应中给出了状态码和标头，但响应中没有实体主体。
205 重置内容 浏览器应清除用于此事务的表单以获取其他输入。
206部分内容 服务器正在返回请求大小的部分数据。用于响应指定Range标头的请求。服务器必须使用Content-Range标头指定响应中包含的范围。

3xx：重定向

信息： 描述：
300多项选择 一个链接列表。用户可以选择一个链接并转到该位置。最多五个地址  
301 永久重定向 请求的页面已移至新网址 
302 找到 请求的页面已临时移动到新的 url 
303 查看其他 请求的页面可以在不同的 url 下找到 
304 未修改 这是对If-Modified-Since或If-None-Match标头的响应代码，其中 URL 自指定日期以来未修改。
305 使用代理 请求的 URL 必须通过Location标头中提到的代理访问。
306未使用 此代码在以前的版本中使用过。不再使用，但保留代码
307临时重定向 请求的页面已临时移动到新的 url

4xx：客户端错误

信息： 描述：
400 错误请求 服务器不理解请求
401未经授权 请求的页面需要用户名和密码
402 需要付款 您还不能使用此代码
403 禁止 被请求的页面被禁止访问
404 未找到 服务器找不到请求的页面
405 方法不允许 请求中指定的方法不被允许
406 不可接受 服务器只能生成客户端不接受的响应
407 需要代理身份验证 您必须先通过代理服务器进行身份验证，然后才能提供此请求
408 请求超时 请求花费的时间比服务器准备等待的时间长
409 冲突 由于冲突，请求无法完成
410 不复存在的 请求的页面不再可用 
411 长度要求 “内容长度”未定义。没有它，服务器将不接受请求 
412 前置条件失败 请求中给出的前提条件被服务器评估为 false
413请求实体太大 服务器不会接受请求，因为请求实体太大
414 请求 URL 太长 服务器不会接受请求，因为 url 太长。当您将“发布”请求转换为具有长查询信息的“获取”请求时发生 
415 不支持的媒体类型 服务器不会接受请求，因为不支持媒体类型 
416 请求的范围不满足 请求的字节范围不可用且超出范围。
417 期望失败 此服务器无法满足在 Expect 请求标头字段中给出的期望。

5xx：服务器错误

信息： 描述：
500内部服务器错误 请求未完成。服务器遇到了意外情况
501 未实施 请求未完成。服务器不支持所需的功能
502错误的网关 请求未完成。服务器收到来自上游服务器的无效响应
503服务不可用 请求未完成。服务器暂时超载或停机
504网关超时 网关已超时
505 不支持的 HTTP 版本 服务器不支持“http协议”版本

HTTP - 标头字段

HTTP 标头字段提供有关请求或响应或消息正文中发送的对象的必需信息。HTTP 消息头有以下四种类型：

  • 一般标头：这些头域对请求和响应消息都通用。

  • 客户端请求标头：这些标头字段仅适用于请求消息。

  • 服务器响应标头：这些标头字段仅适用于响应消息。

  • 实体标头：这些标头字段定义有关实体主体的元信息，或者，如果没有主体存在

一般标头

Cache-control

Cache-Control 通用标头字段用于指定所有缓存系统必须遵守的指令。以下是语法：

Cache-Control : cache-request-directive|cache-response-directive

HTTP 客户端或服务器可以使用Cache-control通用标头来指定缓存的参数或从缓存中请求某些类型的文档。缓存指令在逗号分隔的列表中指定。例如：

Cache-control: no-cache

客户端可以在其 HTTP 请求中使用以下重要的缓存请求指令：

序列号缓存请求指令和说明
1no-cache
在没有成功重新验证原始服务器的情况下，缓存不得使用响应来满足后续请求。
2no-store
缓存不应存储有关客户端请求或服务器响应的任何内容。
3max-age = seconds
表示客户端愿意接受年龄不大于指定时间（以秒为单位）的响应。
4max-stale [ = seconds ]
表示客户端愿意接受超过其过期时间的响应。如果给出秒数，则它的过期时间不得超过该时间。
5min-fresh = seconds
表示客户端愿意接受一个新鲜度不小于当前年龄加上指定时间（以秒为单位）的响应。
6no-transform
不要转换实体主体。
7only-if-cached
不检索新数据。仅当文档在缓存中时，缓存才能发送文档，并且不应联系原始服务器以查看是否存在较新的副本。

服务器可以在其 HTTP 响应中使用以下重要的缓存响应指令：

序列号缓存请求指令和说明
1public
表示响应可以被任何缓存缓存。
2private
表示响应消息的全部或部分是针对单个用户的，并且不能由共享缓存进行缓存。
3no-cache
在没有成功重新验证原始服务器的情况下，缓存不得使用响应来满足后续请求。
4no-store
缓存不应存储有关客户端请求或服务器响应的任何内容。
5no-transform
不要转换实体主体。
6must-revalidate
缓存在使用之前必须验证过时文档的状态，过期的不应该使用。
7proxy-revalidate
proxy-revalidate 指令与 must-revalidate 指令具有相同的含义，除了它不适用于非共享用户代理缓存。
8max-age = seconds
表示客户端愿意接受年龄不大于指定时间（以秒为单位）的响应。
9s-maxage = seconds
该指令指定的最大年龄覆盖了 max-age 指令或 Expires 标头指定的最大年龄。私有缓存始终忽略 s-maxage 指令。

Connection

Connection general-header 字段允许发送者指定该特定连接所需的选项，并且不能由代理通过进一步的连接进行通信。以下是使用连接头的简单语法：

Connection : "Connection"

HTTP/1.1 为发送者定义了“关闭”连接选项，以表示在响应完成后连接将被关闭。例如：

Connection: Closed

默认情况下，HTTP 1.1 使用持久连接，其中连接不会在事务后自动关闭。另一方面，HTTP 1.0 默认没有持久连接。如果 1.0 客户端希望使用持久连接，它使用keep-alive参数，如下所示：

Connection: keep-alive

Date

所有 HTTP 日期/时间戳必须以格林威治标准时间 (GMT) 表示，无一例外。HTTP 应用程序可以使用以下三种日期/时间戳表示中的任何一种：

Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format

这里第一种格式是最优选的。

Pragma

Pragma 通用标头字段用于包含特定于实现的指令，这些指令可能适用于请求/响应链中的任何接收者。例如：

Pragma: no-cache

HTTP/1.0 中定义的唯一指令是 no-cache 指令，并在 HTTP 1.1 中维护以实现向后兼容性。将来不会定义新的 Pragma 指令。

Trailer

Trailer 通用字段值指示给定的头部字段集存在于使用分块传输编码编码的消息的尾部中。以下是 Trailer 头字段的语法：

Trailer : field-name

Trailer 标头字段中列出的消息标头字段不得包含以下标头字段：

  • Transfer-Encoding

  • Content-Length

  • Trailer

Transfer-Encoding

Transfer-Encoding通用标头字段指示已将哪种类型的转换应用于消息正文，以便在发送者和接收者之间安全地传输它。这与内容编码不同，因为传输编码是消息的属性，而不是实体主体的属性。以下是 Transfer-Encoding 头域的语法：

Transfer-Encoding: chunked

所有传输编码值都不区分大小写。

Upgrade

Upgrade通用标头允许客户端指定它支持的其他通信协议，并且如果服务器发现它适合切换协议，则希望使用这些协议。例如：

Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

Upgrade 标头字段旨在提供一种从 HTTP/1.1 转换到其他不兼容协议的简单机制

Via

网关和代理必须使用 Via 通用报头来指示中间协议和接收者。例如，请求消息可以从 HTTP/1.0 用户代理发送到代号为“fred”的内部代理，该代理使用 HTTP/1.1 将请求转发到 nowhere.com 上的公共代理，该代理通过以下方式完成请求将其转发到位于 www.ics.uci.edu 的源服务器。www.ics.uci.edu 收到的请求将具有以下 Via 头字段：

Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

Upgrade 标头字段旨在提供一种从 HTTP/1.1 转换到其他不兼容协议的简单机制

Warning

Warning通用标头用于携带有关消息状态或转换的附加信息，这些信息可能不会反映在消息中。一个响应可能带有多个警告标头。

Warning : warn-code SP warn-agent SP warn-text SP warn-date

客户端请求标头

Accept

Accept request-header 字段可用于指定响应可接受的某些媒体类型。以下是一般语法：

Accept: type/subtype [q=qvalue]

多种媒体类型可以用逗号分隔，可选的 qvalue 表示接受类型的可接受质量级别，范围为 0 到 1。以下是示例：

Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c

这将被解释为text/html和text/xc是首选媒体类型，但如果它们不存在，则发送text/x-dvi实体，如果不存在，则发送text/plain实体。

Accept-Charset

Accept-Charset请求头字段可用于指示响应可接受的字符集。以下是一般语法：

Accept-Charset: character_set [q=qvalue]

多个字符集可以用逗号分隔，可选的 qvalue 表示非首选字符集的可接受质量级别，范围为 0 到 1。以下是示例：

Accept-Charset: iso-8859-5, unicode-1-1; q=0.8

特殊值“*”，如果存在于Accept-Charset字段中，则匹配每个字符集，如果不存在Accept-Charset标头，则默认为可接受任何字符集。

Accept-Encoding

Accept-Encoding请求头字段与Accept 类似，但限制了响应中可接受的内容编码。以下是一般语法：

Accept-Encoding: encoding types

以下是示例：

Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

Accept-Language

Accept-Language请求标头字段类似于 Accept，但限制了作为对请求的响应首选的自然语言集。以下是一般语法：

Accept-Language: language [q=qvalue]

多种语言可以用逗号分隔，可选的 qvalue 表示非首选语言的可接受质量级别，范围为 0 到 1。以下是一个示例：

Accept-Language: da, en-gb;q=0.8, en;q=0.7

Authorization

Authorization request-header 字段值包含凭据，其中包含正在请求的资源领域的用户代理的身份验证信息。以下是一般语法：

Authorization : credentials

HTTP/1.0 规范定义了 BASIC 授权方案，其中授权参数为以 base 64 编码的username:password字符串。示​​例如下：

Authorization: BASIC Z3Vlc3Q6Z3Vlc3QxMjM=

解码为guest:guest123的值，其中guest是用户 ID，guest123是密码。

Cookie

Cookie请求标头字段值包含为该 URL 存储的名称/值对信息。以下是一般语法：

Cookie: name=value

多个 cookie 可以用分号分隔，如下所示：

Cookie: name1=value1;name2=value2;name3=value3

Expect

Expect请求头字段用于指示客户端需要特定的服务器行为。以下是一般语法：

Expect : 100-continue | expectation-extension

如果服务器接收到包含 Expect 字段的请求，该字段包含它不支持的期望扩展，它必须以 417（期望失败）状态响应。

From

From request-header 字段包含控制请求用户代理的人类用户的Internet 电子邮件地址。下面是一个简单的例子：

From: webmaster@w3.org

此标头字段可用于记录目的，并用作识别无效或不需要的请求来源的方法。

Host

Host请求头字段用于指定被请求资源的 Internet 主机和端口号。以下是一般语法：

Host : "Host" ":" host [ ":" port ] ;

没有任何尾随端口信息的主机意味着默认端口，即 80。例如，在源服务器上对http://www.w3.org/pub/WWW/的请求将是：

GET /pub/WWW/ HTTP/1.1
Host: www.w3.org

If-Match

If-Match请求标头字段与一种使其成为条件的方法一起使用。仅当此标记中的给定值与ETag表示的给定实体标记匹配时，此标头才请求服务器执行请求的方法。以下是一般语法：

If-Match : entity-tag

星号 (*) 匹配任何实体，并且仅当实体存在时事务才会继续。以下是可能的示例：

If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: *

如果没有一个实体标签匹配，或者如果给出了“*”并且当前不存在实体，则服务器不能执行请求的方法，并且必须返回 412（Precondition Failed）响应。

If-Modified-Since

If-Modified-Since请求头字段与一种方法一起使用，使其有条件。如果请求的 URL 在此字段中指定的时间后没有被修改，则不会从服务器返回实体；相反，将返回没有任何消息正文的 304（未修改）响应。以下是一般语法：

If-Modified-Since : HTTP-date

该字段的一个示例是：

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

如果没有一个实体标签匹配，或者如果给出了“*”并且当前不存在实体，则服务器不能执行请求的方法，并且必须返回 412（Precondition Failed）响应。

If-None-Match

If-None-Match请求头字段与一种方法一起使用，使其有条件。仅当此标记中的给定值之一与ETag表示的给定实体标记匹配时，此标头才请求服务器执行请求的方法。以下是一般语法：

If-None-Match : entity-tag

星号 (*) 匹配任何实体，并且仅当实体不存在时事务才会继续。以下是可能的示例：

If-None-Match: "xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: *

If-Range

If-Range请求标头字段可以与条件 GET 一起使用，以仅请求丢失的实体部分（如果未更改）和整个实体（如果已更改）。以下是一般语法：

If-Range : entity-tag | HTTP-date

可以使用实体标签或日期来标识已收到的部分实体。例如：

If-Range: Sat, 29 Oct 1994 19:43:31 GMT

这里如果文档自给定日期以来没有被修改，则服务器返回 Range 标头给出的字节范围，否则返回所有新文档。

If-Unmodified-Since

If-Unmodified-Since请求头字段与一种方法一起使用，使其有条件。以下是一般语法：

If-Unmodified-Since : HTTP-date

如果请求的资源自此字段中指定的时间以来没有被修改，则服务器应该执行请求的操作，就好像 If-Unmodified-Since 标头不存在一样。例如：

If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

如果请求通常会导致 2xx 或 412 状态以外的任何状态，则应忽略If-Unmodified-Since标头。

Max-Forwards

Max-Forwards请求头字段提供了一种机制，带有 TRACE 和 OPTIONS 方法来限制可以将请求转发到下一个入站服务器的代理或网关的数量。以下是一般语法：

Max-Forwards : n

Max-Forwards 值是一个十进制整数，表示该请求消息可以被转发的剩余次数。这对于使用 TRACE 方法进行调试非常有用，可以避免无限循环。例如：

Max-Forwards : 5

对于 HTTP 规范中定义的所有其他方法，可以忽略 Max-Forwards 头字段。

Proxy-Authorization

Proxy-Authorization请求头字段允许客户端向需要身份验证的代理标识自己（或其用户）。以下是一般语法：

Proxy-Authorization : credentials

Proxy-Authorization 字段值由包含用户代理的身份验证信息的凭据组成，用于代理和/或被请求资源的领域。

Range

Range request-header 字段指定从文档请求的内容的部分范围。以下是一般语法：

Range: bytes-unit=first-byte-pos "-" [last-byte-pos]

byte-range-spec 中的 first-byte-pos 值给出了范围内第一个字节的字节偏移量。last-byte-pos 值给出了范围内最后一个字节的字节偏移量；也就是说，指定的字节位置包括在内。您可以将字节单位指定为字节字节偏移量从零开始。下面是一个简单的例子：

- The first 500 bytes 
Range: bytes=0-499

- The second 500 bytes
Range: bytes=500-999

- The final 500 bytes
Range: bytes=-500

- The first and last bytes only
Range: bytes=0-0,-1

可以列出多个范围，用逗号分隔。如果缺少逗号分隔的字节范围中的第一个数字，则假定该范围从文档末尾开始计数。如果缺少第二个数字，则范围是字节 n 到文档末尾。

Referer

Referer请求头字段允许客户端指定请求 URL 的资源的地址 (URI)。以下是一般语法：

Referer : absoluteURI | relativeURI

下面是一个简单的例子：

参考：http://www.tutorialspoint.org/http/index.htm

如果字段值是相对 URI，则应相对于Request-URI进行解释。

TE

TE request-header 字段指示它愿意在响应中接受什么扩展传输编码，以及它是否愿意接受分块传输编码中的尾部字段。以下是一般语法：

TE   : t-codings

关键字“trailers”的存在表明客户端愿意接受分块传输编码中的预告片字段，并且可以通过以下任何一种方式指定：

TE: deflate
TE:
TE: trailers, deflate;q=0.5

如果 TE 字段值为空或不存在 TE 字段，则唯一的传输编码是分块的。没有传输编码的消息总是可以接受的。

User-Agent

User-Agent request-header 字段包含有关发起请求的用户代理的信息。以下是一般语法：

User-Agent : product | comment

例子：

User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

服务器响应标头

Accept-Ranges

Accept-Ranges响应头字段允许服务器指示其接受资源的范围请求。以下是一般语法：

Accept-Ranges  : range-unit | none

例如，接受字节范围请求的服务器可能会发送

Accept-Ranges: bytes

不接受任何类型的资源范围请求的服务器可以发送：

Accept-Ranges: none

这将建议客户端不要尝试范围请求。

Age

Age response-header 字段传达了发送者对自源服务器生成响应（或其重新验证）以来的时间量的估计。以下是一般语法：

Age : delta-seconds

Age值是非负十进制整数，以秒为单位表示时间。下面是一个简单的例子：

Age: 1030

包含缓存的 HTTP/1.1 服务器必须在其缓存生成的每个响应中包含 Age 标头字段。

ETag

ETag响应头字段为请求的变体提供实体标签的当前值。以下是一般语法：

ETag :  entity-tag

以下是简单的例子：

ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""

Location

Location response-header 字段用于将接收者重定向到 Request-URI 以外的位置以完成。以下是一般语法：

Location : absoluteURI

下面是一个简单的例子：

Location: http://www.tutorialspoint.org/http/index.htm

Content-Location 标头字段与 Location 的不同之处在于 Content-Location 标识请求中包含的实体的原始位置。

Proxy-Authenticate

Proxy-Authenticate response-header 字段必须包含在 407（需要代理身份验证）响应中。以下是一般语法：

Proxy-Authenticate  : challenge

Retry-After

Retry-After response-header 字段可以与 503（服务不可用）响应一起使用，以指示服务预计对请求客户端不可用的时间。以下是一般语法：

Retry-After : HTTP-date | delta-seconds

下面是两个简单的例子：

Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120

在后一个示例中，延迟为 2 分钟。

Server

Server response-header 字段包含有关源服务器用于处理请求的软件的信息。以下是一般语法：

Server : product | comment

下面是一个简单的例子：

Server: Apache/2.2.14 (Win32)

如果通过代理转发响应，则代理应用程序不得修改服务器响应标头。

Set-Cookie

Set-Cookie响应标头字段包含要为该 URL 保留的名称/值对信息。以下是一般语法：

Set-Cookie: NAME=VALUE; OPTIONS

Set-Cookie 响应标头包含令牌 Set-Cookie:，后跟一个或多个 cookie 的逗号分隔列表。以下是您可以指定为选项的可能值：

序列号选项和说明
1Comment=comment
此选项可用于指定与 cookie 关联的任何评论。
2Domain=domain
Domain 属性指定cookie 对其有效的域。
3Expires=Date-time
cookie 过期的日期。如果此项为空，则 cookie 将在访问者退出浏览器时过期
4Path=path
Path 属性指定了该cookie 应用到的URL 子集。
5Secure
这指示用户代理仅在安全连接下返回 cookie。

以下是服务器生成的简单 cookie 标头的示例：

Set-Cookie: name1=value1,name2=value2; Expires=Wed, 09 Jun 2021 10:18:14 GMT

Vary

Vary response-header 字段指定实体有多个来源，因此可能会根据指定的请求标头列表而有所不同。以下是一般语法：

Vary : field-name

您可以指定多个以逗号分隔的标头，星号“*”的值表示未指定的参数不限于请求标头。下面是一个简单的例子：

Vary: Accept-Language, Accept-Encoding

这里的字段名称不区分大小写。

WWW-Authenticate

WWW-Authenticate response-header 字段必须包含在 401（未授权）响应消息中。该字段值由至少一个指示认证方案的质询和适用于 Request-URI 的参数组成。以下是一般语法：

WWW-Authenticate : challenge

WWW-Authenticate 字段值，因为它可能包含多个质询，或者如果提供了多个 WWW-Authenticate 头字段，质询本身的内容可以包含以逗号分隔的身份验证参数列表。下面是一个简单的例子：

WWW-Authenticate: BASIC realm="Admin"

实体标头

Allow

Allow entity-header 字段列出了由 Request-URI 标识的资源所支持的方法集。以下是一般语法：

Allow : Method

您可以指定多个用逗号分隔的方法。下面是一个简单的例子：

Allow: GET, HEAD, PUT

该字段不能阻止客户端尝试其他方法。

Content-Encoding

Content-Encoding实体头字段用作媒体类型的修饰符。以下是一般语法：

Content-Encoding : content-coding

内容编码是由 Request-URI 标识的实体的特征。下面是一个简单的例子：

Content-Encoding: gzip

如果请求消息中实体的内容编码不被源服务器接受，则服务器应以状态码 415（不支持的媒体类型）进行响应。

Content-Language

Content-Language entity-header 字段描述了封闭实体的目标受众的自然语言。以下是一般语法：

Content-Language : language-tag

对于面向多个受众的内容，可能会列出多种语言。下面是一个简单的例子：

Content-Language: mi, en

Content-Language 的主要目的是允许用户根据用户自己的首选语言来识别和区分实体。

Content-Length

Content-Length entity-header 字段指示发送给接收者的实体主体的大小，以十进制的八进制数表示，或者在 HEAD 方法的情况下，将发送的实体主体的大小具有请求是 GET。以下是一般语法：

Content-Length : DIGITS

下面是一个简单的例子：

Content-Length: 3495

任何大于或等于零的 Content-Length 都是有效值。

Content-Location

当该实体可从与请求的资源的 URI 不同的位置访问时，可以使用Content-Location实体标头字段为包含在消息中的实体提供资源位置。以下是一般语法：

Content-Location:  absoluteURI | relativeURI

下面是一个简单的例子：

Content-Location: http://www.tutorialspoint.org/http/index.htm

Content-Location 的值还定义了实体的基本 URI。

Content-MD5

Content-MD5 entity-header 字段可用于提供实体的 MD5 摘要，用于在收到消息时检查消息的完整性。以下是一般语法：

Content-MD5  : md5-digest using base64 of 128 bit MD5 digest as per RFC 1864

下面是一个简单的例子：

Content-MD5  : 8c2d46911f3f5a326455f0ed7a8ed3b3

MD5 摘要是根据实体主体的内容计算的，包括已应用的任何内容编码，但不包括应用于消息主体的任何传输编码。

Content-Range

Content-Range实体标头字段与部分实体主体一起发送，以指定应在完整实体主体中应用部分主体的位置。以下是一般语法：

Content-Range : bytes-unit SP first-byte-pos "-" last-byte-pos

byte-content-range-spec 值的示例，假设实体总共包含 1234 个字节：

- The first 500 bytes:
Content-Range : bytes 0-499/1234

- The second 500 bytes:
Content-Range : bytes 500-999/1234

- All except for the first 500 bytes:
Content-Range : bytes 500-1233/1234

- The last 500 bytes:
Content-Range : bytes 734-1233/1234

当 HTTP 消息包含单个范围的内容时，此内容会与 Content-Range 标头一起传输，而 Content-Length 标头则显示实际传输的字节数。例如，

HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif

Content-Type

Content-Type entity-header 字段指示发送给接收者的实体主体的媒体类型，或者在 HEAD 方法的情况下，如果请求是 GET，则将发送的媒体类型。以下是一般语法：

Content-Type : media-type

下面是一个例子：

Content-Type: text/html; charset=ISO-8859-4

Expires

Expires entity-header 字段给出了响应被认为是陈旧的日期/时间。以下是一般语法：

Expires : HTTP-date

下面是一个例子：

Expires: Thu, 01 Dec 1994 16:00:00 GMT

Last-Modified

Last-Modified实体标头字段指示源服务器认为最后修改变体的日期和时间。以下是一般语法：

Last-Modified: HTTP-date

下面是一个例子：

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

HTTP - 缓存

HTTP 通常用于分布式信息系统，其中可以通过使用响应缓存来提高性能。HTTP/1.1 协议包括许多旨在使缓存工作的元素。

HTTP/1.1 中缓存的目标是在许多情况下消除发送请求的需要，并在许多其他情况下消除发送完整响应的需要。

HTTP/1.1 中的基本缓存机制是对服务器指定过期时间和验证器的缓存的隐式指令。为此，我们使用Cache-Control标头。

Cache-Control标头允许客户端或服务器在请求或响应中传输各种指令。这些指令通常会覆盖默认缓存算法。缓存指令在逗号分隔的列表中指定。例如：

Cache-control: no-cache

客户端可以在其 HTTP 请求中使用以下重要的缓存请求指令：

序列号缓存请求指令和说明
1no-cache
在没有成功重新验证原始服务器的情况下，缓存不得使用响应来满足后续请求。
2no-store
缓存不应存储有关客户端请求或服务器响应的任何内容。
3max-age = seconds
表示客户端愿意接受年龄不大于指定时间（以秒为单位）的响应。
4max-stale [ = seconds ]
表示客户端愿意接受超过其过期时间的响应。如果给出秒数，则它的过期时间不得超过该时间。
5min-fresh = seconds
表示客户端愿意接受一个新鲜度不小于当前年龄加上指定时间（以秒为单位）的响应。
6no-transform
不要转换实体主体。
7only-if-cached
不检索新数据。仅当文档在缓存中时，缓存才能发送文档，并且不应联系原始服务器以查看是否存在较新的副本。

服务器可以在其 HTTP 响应中使用以下重要的缓存响应指令：

序列号缓存响应指令和描述
1public
表示响应可以被任何缓存缓存。
2private
表示响应消息的全部或部分是针对单个用户的，并且不能由共享缓存进行缓存。
3no-cache
在没有成功重新验证原始服务器的情况下，缓存不得使用响应来满足后续请求。
4no-store
缓存不应存储有关客户端请求或服务器响应的任何内容。
5no-transform
不要转换实体主体。
6must-revalidate
缓存在使用之前必须验证过时文档的状态，过期的不应该使用。
7proxy-revalidate
proxy-revalidate 指令与 must-revalidate 指令具有相同的含义，除了它不适用于非共享用户代理缓存。
8max-age = seconds
表示客户端愿意接受年龄不大于指定时间（以秒为单位）的响应。
9s-maxage = seconds
该指令指定的最大年龄覆盖了 max-age 指令或 Expires 标头指定的最大年龄。私有缓存始终忽略 s-maxage 指令。

HTTP - URL 编码

HTTP URL 只能使用 ASCII字符集通过 Internet 发送，该字符集通常包含 ASCII 集之外的字符。所以这些不安全的字符必须替换为一个%后跟两个十六进制数字。

下表显示了字符的 ASCII 符号和它的等号符号，最后是它的替换，它可以在传递给服务器之前在 URL 中使用：

ASCIISymbolReplacement
< 32 Encode with %xx where xx is the hexadecimal representation of the character.
32space+ or %20
33!%21
34"%22
35#%23
36$%24
37%%25
38&%26
39'%27
40(%28
41)%29
42**
43+%2B
44,%2C
45--
46..
47/%2F
4800
4911
5022
5133
5244
5355
5466
5577
5688
5799
58:%3A
59;%3B
60<%3C
61=%3D
62>%3E
63?%3F
64@%40
65AA
66BB
67CC
68DD
69EE
70FF
71GG
72HH
73II
74JJ
75KK
76LL
77MM
78NN
79OO
80PP
81QQ
82RR
83SS
84TT
85UU
86VV
87WW
88XX
89YY
90ZZ
91[%5B
92\%5C
93]%5D
94^%5E
95__
96`%60
97aa
98bb
99cc
100dd
101ee
102ff
103gg
104hh
105ii
106jj
107kk
108ll
109mm
110nn
111oo
112pp
113qq
114rr
115ss
116tt
117uu
118vv
119ww
120xx
121yy
122zz
123{%7B
124|%7C
125}%7D
126~%7E
127 %7F
> 127 Encode with %xx where xx is the hexadecimal representation of the character

HTTP - 安全

HTTP 用于通过 Internet 进行通信，因此应用程序开发人员、信息提供者和用户应该了解 HTTP/1.1 中的安全限制。此讨论不包括对此处提到的问题的最终解决方案，但它确实为降低安全风险提出了一些建议。

个人信息泄露

HTTP 客户端通常知道大量的个人信息，例如用户名、位置、邮件地址、密码、加密密钥等。因此，您应该非常小心，以防止这些信息通过 HTTP 协议无意中泄漏到其他来源。

  • 所有机密信息都应以加密形式存储在服务器端。

  • 揭示服务器的特定软件版本可能会使服务器机器更容易受到已知包含安全漏洞的软件的攻击。

  • 作为通过网络防火墙的门户的代理应采取特殊的预防措施来传输标头信息，以识别防火墙后面的主机。

  • 在 From 字段中发送的信息可能与用户的隐私利益或其站点的安全策略相冲突，因此在用户无法禁用、启用和修改字段内容的情况下不应传输它。

  • 如果引用页面是使用安全协议传输的，则客户端不应在（非安全）HTTP 请求中包含Referer 头字段。

  • 使用 HTTP 协议的服务的作者不应使用基于 GET 的表单来提交敏感数据，因为这将导致该数据被编码在 Request-URI 中

基于文件和路径名的攻击

该文档应仅限于 HTTP 请求返回的文档，这些文档仅是服务器管理员想要的文档。

例如，UNIX、Microsoft Windows 和其他操作系统使用..作为路径组件来指示高于当前目录级别的目录级别。在这样的系统上，HTTP 服务器必须禁止 Request-URI 中的任何此类构造，否则它会允许访问超出预期可通过 HTTP 服务器访问的资源之外的资源。

DNS 欺骗

使用 HTTP 的客户端严重依赖域名服务，因此通常容易受到基于 IP 地址和 DNS 名称故意错误关联的安全攻击。因此，客户端在假设 IP 号码/DNS 名称关联的持续有效性时需要谨慎。

如果 HTTP 客户端缓存主机名查找的结果以实现性能提升，它们必须观察 DNS 上报的 TTL 信息。如果 HTTP 客户端不遵守此规则，它们可能会在先前访问的服务器的 IP 地址更改时被欺骗。

位置标头和欺骗

如果单个服务器支持多个互不信任的组织，则它必须检查在所述组织控制下生成的响应中 Location 和 Content-Location 标头的值，以确保它们不会尝试使资源无效他们没有权力。

身份验证凭据

现有的 HTTP 客户端和用户代理通常会无限期地保留身份验证信息。HTTP/1.1。没有为服务器提供一种方法来指导客户端丢弃这些缓存的凭据，这是一个很大的安全风险。

这个问题的一部分有很多变通方法，因此建议在屏幕保护程序、空闲超时和其他方法中使用密码保护来缓解这个问题固有的安全问题。

代理和缓存

HTTP 代理是中间人，代表了中间人攻击的机会。代理可以访问与安全相关的信息、有关个人用户和组织的个人信息以及属于用户和内容提供商的专有信息。

代理运营商应保护运行代理的系统，就像保护任何包含或传输敏感信息的系统一样。

缓存代理提供了额外的潜在漏洞，因为缓存的内容代表了恶意利用的有吸引力的目标。因此，缓存内容应作为敏感信息加以保护。

HTTP - 消息示例

示例 1

从tutorialspoint.com上运行的 Web 服务器获取hello.htm页面的 HTTP 请求

客户要求

GET /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

服务器响应

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

示例 2

获取在tutorialspoint.com上运行的 Web 服务器上不存在的t.html页面的HTTP 请求

客户要求

GET /t.html HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

服务器响应

HTTP/1.1 404 Not Found
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Content-Type: text/html; charset=iso-8859-1
Connection: close
   
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
   <title>404 Not Found</title>
</head>
<body>
   <h1>Not Found</h1>
   <p>The requested URL /t.html was not found on this server.</p>
</body>
</html>

示例 3

从tutorialspoint.com上运行的 Web 服务器获取hello.htm页面的 HTTP 请求，但请求的 HTTP 版本错误：

客户要求

GET /hello.htm HTTP1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

服务器响应

HTTP/1.1 400 Bad Request
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Content-Type: text/html; charset=iso-8859-1
Connection: close
   
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
   <title>400 Bad Request</title>
</head>
<body>
   <h1>Bad Request</h1>
   <p>Your browser sent a request that this server could not understand.<p>
   <p>The request line contained invalid characters following the protocol string.<p>
</body>
</html>

示例 4

将表单数据发布到在tutorialspoint.com上运行的 Web 服务器上的process.cgi CGI 页面的HTTP 请求。服务器在将它们设置为 cookie 后返回传递的名称：

客户要求

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: text/xml; charset=utf-8
Content-Length: 60
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

first=Zara&last=Ali

服务器响应

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 88
Set-Cookie: first=Zara,last=Ali;domain=tutorialspoint.com;Expires=Mon, 19-
Nov-2010 04:38:14 GMT;Path=/
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Hello Zara Ali</h1>
</body>
</html>
HTTP协议中文网

原文

提供更好的翻译建议