HTTP - 快速指南
超文本传输协议（HTTP）是用于分布式协作超媒体信息系统的应用程序级协议。 这是自1990年以来万维网（即互联网）数据通信的基础.HTTP是一种通用的无状态协议，可以用于其他目的，也可以使用其请求方法，错误代码和标题的扩展。
基本上，HTTP是基于TCP/IP的通信协议，用于在万维网上传递数据（HTML文件，图像文件，查询结果等）。 默认端口为TCP 80，但可以使用其他端口。 它为计算机相互通信提供了一种标准化的方式。 HTTP规范指定客户端如何构造请求数据并将其发送到服务器，以及服务器如何响应这些请求。
基本功能
有以下三个基本功能使HTTP成为简单但功能强大的协议:
HTTP is connectionless: HTTP客户端即。 浏览器启动HTTP请求，并在发出请求后，客户端断开与服务器的连接并等待响应。 服务器处理请求并重新建立与客户端的连接以发回响应。
HTTP is media independent:这意味着，只要客户端和服务器都知道如何处理数据内容，就可以通过HTTP发送任何类型的数据。 客户端和服务器都需要使用适当的MIME类型指定内容类型。
HTTP is stateless:如上所述，HTTP是无连接的，这是HTTP是无状态协议的直接结果。 服务器和客户端仅在当前请求期间相互了解。 之后，他们两个都忘记了彼此。 由于协议的这种性质，客户端和浏览器都不能在跨网页的不同请求之间保留信息。
HTTP/1.0为每个请求/响应交换使用新连接，其中HTTP/1.1连接可用于一个或多个请求/响应交换。
基础架构
下图显示了Web应用程序的一个非常基本的体系结构，并描述了HTTP的位置:
HTTP协议是基于客户端/服务器架构的请求/响应协议，其中Web浏览器，机器人和搜索引擎等充当HTTP客户端，Web服务器充当服务器。
Client
HTTP客户端以请求方法，URI和协议版本的形式向服务器发送请求，然后是类似MIME的消息，其中包含请求修饰符，客户端信息以及TCP/IP连接上可能的正文内容。
服务器
HTTP服务器以状态行响应，包括消息的协议版本和成功或错误代码，然后是包含服务器信息，实体元信息和可能的实体主体内容的类似MIME的消息。
HTTP - Parameters
本章将以通信中使用的方式列出一些重要的HTTP协议参数及其语法。 例如，日期格式，URL格式等。这将帮助您在编写HTTP客户端或服务器程序时构建请求和响应消息。 您将在后续章节中看到这些参数的完整用法，同时解释HTTP请求和响应的消息结构。
HTTP版本
HTTP使用《major》.《minor》编号方案来指示协议的版本。 HTTP消息的版本由第一行中的HTTP-Version字段指示。 以下是指定HTTP版本号的一般语法:
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
例子 (Example)
HTTP/1.0
or
HTTP/1.1
Uniform Resource Identifiers (URI)
统一资源标识符（URI）是简单格式化的，不区分大小写的字符串，包含用于标识资源的名称，位置等，例如网站，Web服务等。用于HTTP的URI的一般语法如下:
URI = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
如果port为空或未给出，则假定HTTP为端口80，空abs_path等于abs_path为“/”。 除reserved和unsafe集合之外的字符等同于它们的“”％“HEX HEX”编码。
例子 (Example)
以下两个URI是等效的:
http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html
Date/Time Formats
所有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。
例子 (Example)
以下是有效的字符集:
US-ASCII
or
ISO-8859-1
or
ISO-8859-7
内容编码
内容ecoding值指示已经使用编码算法在将内容传递到网络之前对内容进行编码。 内容编码主要用于允许文档被压缩或以其他方式有用地转换而不会丢失身份。
所有内容编码值都不区分大小写。 HTTP/1.1使用Accept-Encoding和Content-Encoding头字段中的内容编码值，我们将在后续章节中看到。
例子 (Example)
以下是有效的编码方案:
Accept-encoding: gzip
or
Accept-encoding: compress
or
Accept-encoding: deflate
媒体类型
HTTP使用Content-Type和Accept标头字段中的Internet媒体类型，以提供开放和可扩展的数据类型和类型协商。 所有Media-type值都在Internet Assigned Number Authority（（IANA）中注册。以下是指定媒体类型的一般语法:
media-type = type "/" subtype *( ";" parameter )
类型，子类型和参数属性名称不区分大小写。
例子 (Example)
Accept: image/gif
语言标签
HTTP使用Accept-Language和Content-Language字段中的语言标记。 语言标记由1个或多个部分组成:主要语言标记和可能为空的子标记系列:
language-tag = primary-tag *( "-" subtag )
标签内不允许有空格，所有标签都不区分大小写。
例子 (Example)
示例标签包括:
en, en-US, en-cockney, i-cherokee, x-pig-latin
任何两个字母的主要标签是ISO-639语言缩写，任何两个字母的初始子标签是ISO-3166国家代码。
HTTP - Messages
HTTP基于客户端 - 服务器体系结构模型和无状态请求/响应协议，该协议通过在可靠的TCP/IP连接上交换消息来进行操作。
HTTP“客户端”是为了发送一个或多个HTTP请求消息而与服务器建立连接的程序（Web浏览器或任何其他客户端）。 HTTP“服务器”是一个程序（通常是Web服务器，如Apache Web服务器或Internet信息服务IIS等），它接受连接以通过发送HTTP响应消息来提供HTTP请求。
HTTP利用统一资源标识符（URI）来标识给定资源并建立连接。 建立连接后， HTTP messages的传递格式类似于Internet邮件[RFC5322]和多用途Internet邮件扩展（MIME）[RFC2045]所使用的格式。 这些消息包括从客户端到服务器的requests以及从服务器到客户端的responses ，其具有以下格式:
HTTP-message = <Request> | <Response> ; HTTP/1.1 messages
HTTP请求和HTTP响应使用RFC 822的通用消息格式来传输所需的数据。 此通用消息格式包含以下四个项目。
None- A Start-line
- 零个或多个标题字段后跟CRLF
- 空行（即CRLF前面没有任何内容的行），表示标题字段的结尾
- 可选的消息体
以下部分将解释HTTP消息中使用的每个实体。
Message Start-Line
起始行将具有以下通用语法:
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 deader字段提供有关请求或响应的所需信息，或有关在消息正文中发送的对象的信息。 有以下四种类型的HTTP消息头:
General-header:这些头字段对请求和响应消息都具有普遍适用性。
Request-header:这些标头字段仅适用于请求消息。
Response-header:这些标头字段仅适用于响应消息。
Entity-header:这些标题字段定义关于实体主体的元信息，或者，如果没有主体，则定义元信息
所有上述标题都遵循相同的通用格式，每个标题字段由一个名称后跟冒号（:)和字段值组成，如下所示:
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 - Requests
HTTP客户端以请求消息的形式向服务器发送HTTP请求，其中包括以下格式:
None- 请求行
- 零个或多个标题（General | Request | Entity）字段后跟CRLF
- 空行（即CRLF前面没有任何内容的行），表示标题字段的结尾
- 可选的消息体
以下部分将解释HTTP消息中使用的每个实体。
Message Request-Line
Request-Line以方法标记开头，后跟Request-URI和协议版本，以CRLF结尾。 元素由空格SP字符分隔。
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
让我们讨论Request-Line中提到的每个部分。
请求方法
请求Method指示要对给定Request-URI标识的资源执行的方法。 该方法区分大小写，应始终以大写形式提及。 以下是HTTP/1.1中支持的方法
| SN | 方法和描述 |
|---|---|
| 1 | GET GET方法用于使用给定的URI从给定服务器检索信息。 使用GET的请求应仅检索数据，并且不应对数据产生其他影响。 |
| 2 | HEAD与GET相同，但仅传输状态行和标题部分。 |
| 3 | POST POST请求用于将数据发送到服务器，例如使用HTML表单的客户信息，文件上载等。 |
| 4 | PUT用上传的内容替换目标资源的所有当前表示。 |
| 5 | DELETE删除URI给出的目标资源的所有当前表示。 |
| 6 | CONNECT建立到给定URI标识的服务器的隧道。 |
| 7 | OPTIONS描述目标资源的通信选项。 |
| 8 | TRACE沿目标资源的路径执行消息环回测试。 |
Request-URI
Request-URI是统一资源标识符，用于标识应用请求的资源。 以下是指定URI的最常用表单:
Request-URI = "*" | absoluteURI | abs_path | authority
| SN | 方法和描述 |
|---|---|
| 1 | 当HTTP请求不适用于特定资源但使用服务器本身时，将使用星号* ，并且仅当使用的方法不一定适用于资源时才允许使用星号* 。 例如: OPTIONS * HTTP/1.1 |
| 2 | 在对代理进行HTTP请求时使用absoluteURI 。 请求代理转发请求或从有效缓存中为其提供服务，并返回响应。 例如: GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1 |
| 3 | Request-URI的最常见形式是用于标识源服务器或网关上的资源。 例如，希望直接从源服务器检索上述资源的客户端将创建到主机“www.w3.org”的端口80的TCP连接并发送以下行: GET /pub/WWW/TheProject.html HTTP/1.1 Host: www.w3.org 注意绝对路径不能为空; 如果原始URI中不存在，则必须以“/”（服务器根目录）给出 |
请求标头字段
当我们学习HTTP头字段时，我们将在单独的章节中研究General-header和Entity-header。 现在让我们检查什么是Request头字段。
request-header字段允许客户端将有关请求以及客户端本身的其他信息传递给服务器。 这些字段充当请求修饰符，并且可以使用以下重要的Request-header字段，可以根据需要使用这些字段。
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请求，从iowiki.com上运行的web服务器获取hello.htm页面
GET /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.iowiki.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.iowiki.com
Content-Type: application/x-www-form-urlencoded
Content-Length: <b class="notranslate">length</b>
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.iowiki.com
Content-Type: text/xml; charset=utf-8
Content-Length: <b class="notranslate">length</b>
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 - Responses
在接收并解释请求消息之后，服务器响应HTTP响应消息:
None- A Status-line
- 零个或多个标题（General | Response | Entity）字段后跟CRLF
- 空行（即CRLF前面没有任何内容的行），表示标题字段的结尾
- 可选的消息体
以下部分将解释HTTP消息中使用的每个实体。
Message Status-Line
状态行由协议版本后跟数字状态代码及其相关的文本短语组成。 元素由空格SP字符分隔。
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
我们来讨论Status-Line中提到的每个部分。
HTTP版本
支持HTTP版本1.1的服务器将返回以下版本信息:
HTTP-Version = HTTP/1.1
状态代码
Status-Code元素是一个3位整数，其中Status-Code的第一个数字定义了响应类，后两个数字没有任何分类角色。 第一个数字有5个值:
| SN | 代码和描述 |
|---|---|
| 1 | 1xx: Informational这意味着收到请求并继续处理。 |
| 2 | 2xx: Success这意味着该行动已成功接收，理解和接受。 |
| 3 | 3xx: Redirection这意味着必须采取进一步措施才能完成请求。 |
| 4 | 4xx: Client Error这意味着请求包含错误的语法或无法满足 |
| 5 | 5xx: Server Error服务器无法满足明显有效的请求 |
HTTP状态代码是可扩展的，并且不需要HTTP应用程序来理解所有已注册状态代码的含义。 所有状态代码的列表已在单独的章节中给出，供您参考。
响应标头字段
当我们学习HTTP头字段时，我们将在单独的章节中研究General-header和Entity-header。 现在让我们检查什么是Response头字段。
响应标头字段允许服务器传递有关无法放入状态行的响应的其他信息。 这些头字段提供有关服务器的信息以及有关Request-URI标识的资源的进一步访问。
Accept-Ranges
Age
ETag
Location
Proxy-Authenticate
Retry-After
Server
Vary
WWW-Authenticate
您可以引入自定义字段，以防您要编写自己的自定义Web客户端和服务器。
响应消息示例
现在让我们把它们放在一起，形成一个HTTP响应，用于从在iowiki.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>
以下是HTTP响应消息的示例，显示Web服务器找不到请求页面时的错误情况:
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>
以下是HTTP响应消息的示例，显示Web服务器在给定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 - Methods
HTTP/1.1的常用方法集定义如下，可以根据需求扩展该集。 这些方法名称区分大小写，必须以大写形式使用。
| SN | 方法和描述 |
|---|---|
| 1 | GET GET方法用于使用给定的URI从给定服务器检索信息。 使用GET的请求应仅检索数据，并且不应对数据产生其他影响。 |
| 2 | HEAD与GET相同，但仅传输状态行和标题部分。 |
| 3 | POST POST请求用于将数据发送到服务器，例如使用HTML表单的客户信息，文件上载等。 |
| 4 | PUT用上传的内容替换目标资源的所有当前表示。 |
| 5 | DELETE删除URI给出的目标资源的所有当前表示。 |
| 6 | CONNECT建立到给定URI标识的服务器的隧道。 |
| 7 | OPTIONS描述目标资源的通信选项。 |
| 8 | TRACE沿目标资源的路径执行消息环回测试。 |
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.iowiki.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.iowiki.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 Method
当您想要向服务器发送一些数据时使用POST方法，例如文件更新，表单数据等。以下是一个简单的示例，它使用POST方法将表单数据发送到服务器，该服务器将由process.cgi，最后会返回一个响应:
POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.iowiki.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.iowiki.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方法用于请求服务器删除给定URL指定的位置的文件。 以下示例请求服务器删除服务器根目录下的给定文件hello.htm :
DELETE /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.iowiki.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方法通过HTTP建立到Web服务器的网络连接。 以下示例请求与主机iowiki.com上运行的Web服务器建立连接:
CONNECT www.iowiki.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方法来查找Web服务器支持的HTTP方法和其他选项。 客户端可以指定OPTIONS方法的URL，也可以指定星号（*）来引用整个服务器。 以下示例请求在iowiki.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.iowiki.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.iowiki.com
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
HTTP - Status Codes
服务器响应中的Status-Code元素是一个3位整数，其中Status-Code的第一个数字定义了响应类，后两个数字没有任何分类角色。 第一个数字有5个值:
| SN | 代码和描述 |
|---|---|
| 1 | 1xx: Informational这意味着收到请求并继续处理。 |
| 2 | 2xx: Success这意味着该行动已成功接收，理解和接受。 |
| 3 | 3xx: Redirection这意味着必须采取进一步措施才能完成请求。 |
| 4 | 4xx: Client Error这意味着请求包含错误的语法或无法满足 |
| 5 | 5xx: Server Error服务器无法满足明显有效的请求 |
HTTP状态代码是可扩展的，并且不需要HTTP应用程序来理解所有已注册状态代码的含义。 以下是所有状态代码的列表。
1xx:信息
| 信息: | 描述: |
|---|---|
| 100 Continue | 服务器只收到请求的一部分，但只要它没有被拒绝，客户端就应该继续请求 |
| 101交换协议 | 服务器切换协议 |
2xx:成功
| 信息: | 描述: |
|---|---|
| 200 OK | The request is OK |
| 201 Created | 请求已完成，并且已创建新资源 |
| 202 Accepted | 请求被接受处理，但处理不完整 |
| 203 Non-authoritative Information | 实体标头中的信息来自本地或第三方副本，而不是来自原始服务器。 |
| 204没有内容 | 响应中给出了状态代码和标头，但回复中没有实体主体。 |
| 205重置内容 | 浏览器应清除用于此事务的表单以获取其他输入。 |
| 206部分内容 | 服务器返回所请求大小的部分数据。 用于响应指定Range标头的请求。 服务器必须使用Content-Range标头指定响应中包含的Content-Range 。 |
3xx:重定向
| 信息: | 描述: |
|---|---|
| 300多种选择 | 链接列表。 用户可以选择链接并转到该位置。 最多五个地址 |
| 301 Moved Permanently | 请求的页面已移至新网址 |
| 302 Found | 请求的页面暂时移动到新的URL |
| 303 See Other | 请求的页面可以在不同的URL下找到 |
| 304 Not Modified | 这是If-Modified-Since或If-None-Match标头的响应代码，其中URL自指定日期以来未被修改。 |
| 305 Use Proxy | 必须通过Location标头中提到的代理访问请求的URL。 |
| 306 Unused | 此代码用于以前的版本。 它已不再使用，但代码保留 |
| 307 Temporary Redirect | 请求的页面暂时移动到新的URL |
4xx:客户端错误
| 信息: | 描述: |
|---|---|
| 400 Bad Request | 服务器不理解请求 |
| 401 Unauthorized | 请求的页面需要用户名和密码 |
| 402 Payment Required | You can not use this code yet |
| 403 Forbidden | 禁止访问所请求的页面 |
| 404 Not Found | 服务器找不到请求的页面 |
| 405 Method Not Allowed | 不允许在请求中指定的方法 |
| 406 Not Acceptable | 服务器只能生成客户端不接受的响应 |
| 407 Proxy Authentication Required | 在提供此请求之前，您必须使用代理服务器进行身份验证 |
| 408 Request Timeout | 请求花费的时间比服务器准备等待的时间长 |
| 409 Conflict | 由于冲突，请求无法完成 |
| 410 Gone | 请求的页面不再可用 |
| 411 Length Required | “内容长度”未定义。 没有它，服务器将不接受请求 |
| 412 Precondition Failed | 请求中给出的前提条件由服务器评估为false |
| 413请求实体太大 | 服务器不接受请求，因为请求实体太大 |
| 414 Request-url Too Long | 服务器不接受请求，因为网址太长。 将“post”请求转换为带有长查询信息的“get”请求时发生 |
| 415 Unsupported Media Type | 服务器不接受请求，因为不支持媒体类型 |
| 416请求的范围不满意 | 请求的字节范围不可用且超出范围。 |
| 417 Expectation Failed | 此服务器无法满足Expect request-header字段中给出的期望。 |
5xx:服务器错误
| 信息: | 描述: |
|---|---|
| 500内部服务器错误 | 请求未完成。 服务器遇到意外情况 |
| 501 Not Implemented | 请求未完成。 服务器不支持所需的功能 |
| 502 Bad Gateway | 请求未完成。 服务器从上游服务器收到无效响应 |
| 503服务不可用 | 请求未完成。 服务器暂时超载或关闭 |
| 504 Gateway Timeout | 网关已超时 |
| 505不支持HTTP版本 | 服务器不支持“http协议”版本 |
HTTP - Header Fields
HTTP deader字段提供有关请求或响应的所需信息，或有关在消息正文中发送的对象的信息。 有以下四种类型的HTTP消息头:
General-header:这些头字段对请求和响应消息都具有普遍适用性。
Client Request-header:这些标头字段仅适用于请求消息。
Server Response-header:这些标头字段仅适用于响应消息。
Entity-header:这些标题字段定义关于实体主体的元信息，或者，如果没有主体，则定义元信息
一般标题
缓存控制
Cache-Control通用头字段用于指定所有缓存系统必须遵守的指令。 以下是语法:
Cache-Control : cache-request-directive|cache-response-directive
HTTP客户端或服务器可以使用Cache-control通用头来指定缓存的参数或从缓存中请求某些类型的文档。 缓存指令在逗号分隔列表中指定。 例如:
Cache-control: no-cache
客户端在其HTTP请求中可以使用以下重要的缓存请求指令:
| SN | 缓存请求指令和描述 |
|---|---|
| 1 | no-cache如果没有成功重新验证源服务器，则缓存不得使用响应来满足后续请求。 |
| 2 | no-store缓存不应存储有关客户端请求或服务器响应的任何内容。 |
| 3 | max-age = seconds表示客户端愿意接受年龄不大于指定时间（秒）的响应。 |
| 4 | max-stale [ = seconds ]表示客户端愿意接受超过其到期时间的响应。 如果给出秒数，则不得超过该时间。 |
| 5 | min-fresh = seconds表示客户端愿意接受其新鲜度生命周期不小于其当前年龄加上指定时间（秒）的响应。 |
| 6 | no-transform不转换实体。 |
| 7 | only-if-cached不检索新数据。 缓存只有在缓存中才能发送文档，并且不应该联系源服务器以查看是否存在较新的副本。 |
服务器在其HTTP响应中可以使用以下重要的缓存响应指令:
| SN | 缓存请求指令和描述 |
|---|---|
| 1 | public表示任何缓存都可以缓存响应。 |
| 2 | private表示响应消息的全部或部分内容仅供单个用户使用，不得由共享高速缓存进行高速缓存。 |
| 3 | no-cache如果没有成功重新验证源服务器，则缓存不得使用响应来满足后续请求。 |
| 4 | no-store缓存不应存储有关客户端请求或服务器响应的任何内容。 |
| 5 | no-transform不转换实体。 |
| 6 | must-revalidate缓存必须在使用之前验证过时文档的状态，并且不应使用过期文档。 |
| 7 | proxy-revalidate proxy-revalidate指令与must-revalidate指令具有相同的含义，但它不适用于非共享用户代理缓存。 |
| 8 | max-age = seconds表示客户端愿意接受年龄不大于指定时间（秒）的响应。 |
| 9 | s-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 general-header字段用于包括可能适用于请求/响应链中任何收件人的特定于实现的指令。 例如:
Pragma: no-cache
HTTP/1.0中定义的唯一指令是no-cache指令，并在HTTP 1.1中维护以实现向后兼容。 将来不会定义新的Pragma指令。
Trailer
预告片通用字段值指示给定的标题字段集存在于使用分块传输编码编码的消息的尾部中。 以下是Trailer标题字段的语法:
Trailer : field-name
“预告片”标题字段中列出的邮件标题字段不得包含以下标题字段:
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 general-header用于携带有关消息状态或转换的其他信息，这些信息可能不会反映在消息中。 响应可能带有多个警告标头。
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请求标头字段值由包含所请求资源领域的用户代理的认证信息的凭证组成。 以下是一般语法:
Authorization : credentials
HTTP/1.0规范定义了BASIC授权方案，其中授权参数是username:password以base 64编码的字符串。以下是一个示例:
Authorization: BASIC Z3Vlc3Q6Z3Vlc3QxMjM=
值guest:guest123为guest:guest123 ，其中guest是用户ID， guest123是密码。
Cookie
Cookie请求标头字段值包含为该URL存储的名称/值对信息。 以下是一般语法:
Cookie: name=value
可以使用分号指定多个cookie，如下所示:
Cookie: name1=value1;name2=value2;name3=value3
Expect
Expect request-header字段用于指示客户端需要特定的服务器行为。 以下是一般语法:
Expect : 100-continue | expectation-extension
如果服务器收到包含Expect字段的请求，该字段包含它不支持的期望扩展，则它必须以417（期望失败）状态响应。
从
From request-header字段包含控制请求用户代理的人类用户的Internet电子邮件地址。 以下是一个简单的例子:
From: webmaster@w3.org
该头字段可用于记录目的，并用作识别无效或不需要的请求源的手段。
Host
Host request-header字段用于指定所请求资源的Internet主机和端口号。 以下是一般语法:
Host : "Host" ":" host [ ":" port ] ;
没有任何尾随端口信息的host意味着默认端口，即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 request-header字段允许客户端指定从中请求URL的资源的地址（URI）。 以下是一般语法:
Referer : absoluteURI | relativeURI
以下是一个简单的例子:
Referer: http://www.iowiki.org/http/index.htm
如果字段值是相对URI，则应相对于Request-URI进行解释。
TE
TE请求头字段指示它愿意在响应中接受什么扩展transfer-coding以及它是否愿意接受分块transfer-coding尾部字段。 以下是一般语法:
TE : t-codings
关键字“预告片”的存在表示客户端愿意接受分块传输编码中的预告片字段，并指定其中一种方式:
TE: deflate
TE:
TE: trailers, deflate;q=0.5
如果TE字段值为空或者如果不存在TE字段，则仅对传输编码进行chunked 。 没有传输编码的消息总是可以接受的。
User-Agent
User-Agent请求标头字段包含有关发起请求的用户代理的信息。 以下是一般语法:
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: 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.iowiki.org/http/index.htm
Content-Location头字段与Location的不同之处在于Content-Location标识请求中包含的实体的原始位置。
Proxy-Authenticate
Proxy-Authenticate响应头字段必须作为407（需要代理身份验证）响应的一部分包含在内。 以下是一般语法:
Proxy-Authenticate : challenge
Retry-After
Retry-After响应头字段可以与503（服务不可用）响应一起使用，以指示服务预期对请求客户端不可用的时间。 以下是一般语法:
Retry-After : HTTP-date | delta-seconds
以下是两个简单的例子:
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120
在后一个例子中，延迟是2分钟。
服务器
Server response-header字段包含有关源服务器用于处理请求的软件的信息。 以下是一般语法:
Server : product | comment
以下是一个简单的例子:
Server: Apache/2.2.14 (Win32)
如果通过代理转发响应，则代理应用程序不得修改Server响应标头。
Set-Cookie
Set-Cookie响应头字段包含要为此URL保留的名称/值对信息。 以下是一般语法:
Set-Cookie: NAME=VALUE; OPTIONS
Set-Cookie响应头包括令牌Set-Cookie:，后跟一个或多个cookie的逗号分隔列表。 以下是您可以指定为选项的可能值:
| SN | 选项和说明 |
|---|---|
| 1 | Comment=comment此选项可用于指定与cookie关联的任何注释。 |
| 2 | Domain=domain Domain属性指定cookie有效的域。 |
| 3 | Expires=Date-time cookie过期的日期。 如果这是空白，则访问者退出浏览器时cookie将过期 |
| 4 | Path=path Path属性指定此cookie适用的URL子集。 |
| 5 | Secure这指示用户代理仅在安全连接下返回cookie。 |
以下是服务器生成的简单cookie标头的示例:
Set-Cookie: name1=value1,name2=value2; Expires=Wed, 09 Jun 2021 10:18:14 GMT
Vary
Vary响应头字段指定实体具有多个源，因此可以根据指定的请求头列表而变化。 以下是一般语法:
Vary : field-name
您可以指定由逗号分隔的多个标头，并且星号“*”的值表示未指定的参数不限于请求标头。 以下是一个简单的例子:
Vary: Accept-Language, Accept-Encoding
这里的字段名称不区分大小写。
WWW-Authenticate
WWW-Authenticate响应头字段必须包含在401（未授权）响应消息中。 字段值包括至少一个挑战，该挑战指示适用于Request-URI的认证方案和参数。 以下是一般语法:
WWW-Authenticate : challenge
WWW-验证字段值，因为它可能包含多个质询，或者如果提供了多个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-Length
Content-Length实体头字段指示发送给接收者的实体主体的大小（以十进制数字表示的OCTET），或者在HEAD方法的情况下，实体主体的大小。请求是GET。 以下是一般语法:
Content-Length : DIGITS
以下是一个简单的例子:
Content-Length: 3495
任何大于或等于零的Content-Length都是有效值。
Content-Location
当该实体可从与所请求资源的URI分开的位置访问时， Content-Location实体头字段可用于提供消息中包含的实体的资源位置。 以下是一般语法:
Content-Location: absoluteURI | relativeURI
以下是一个简单的例子:
Content-Location: http://www.iowiki.org/http/index.htm
Content-Location的值还定义了实体的基URI。
Content-MD5
Content-MD5实体标题字段可用于提供实体的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
假设实体包含总共1234个字节的byte-content-range-spec值的示例:
- 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 - Caching
HTTP通常用于分布式信息系统，其中可以通过使用响应缓存来提高性能。 HTTP/1.1协议包括许多旨在使缓存工作的元素。
在HTTP/1.1中缓存的目的是在许多情况下消除发送请求的需要，并且在许多其他情况下无需发送完整响应。
HTTP/1.1中的基本缓存机制是缓存的隐式指令，其中服务器指定到期时间和验证器。 为此，我们使用Cache-Control标头。
Cache-Control标头允许客户端或服务器在请求或响应中传输各种指令。 这些指令通常会覆盖默认的缓存算法。 缓存指令在逗号分隔列表中指定。 例如:
Cache-control: no-cache
客户端在其HTTP请求中可以使用以下重要的缓存请求指令:
| SN | 缓存请求指令和描述 |
|---|---|
| 1 | no-cache如果没有成功重新验证源服务器，则缓存不得使用响应来满足后续请求。 |
| 2 | no-store缓存不应存储有关客户端请求或服务器响应的任何内容。 |
| 3 | max-age = seconds表示客户端愿意接受年龄不大于指定时间（秒）的响应。 |
| 4 | max-stale [ = seconds ]表示客户端愿意接受超过其到期时间的响应。 如果给出秒数，则不得超过该时间。 |
| 5 | min-fresh = seconds表示客户端愿意接受其新鲜度生命周期不小于其当前年龄加上指定时间（秒）的响应。 |
| 6 | no-transform不转换实体。 |
| 7 | only-if-cached不检索新数据。 缓存只有在缓存中才能发送文档，并且不应该联系源服务器以查看是否存在较新的副本。 |
服务器在其HTTP响应中可以使用以下重要的缓存响应指令:
| SN | 缓存响应指令和描述 |
|---|---|
| 1 | public表示任何缓存都可以缓存响应。 |
| 2 | private表示响应消息的全部或部分内容仅供单个用户使用，不得由共享高速缓存进行高速缓存。 |
| 3 | no-cache如果没有成功重新验证源服务器，则缓存不得使用响应来满足后续请求。 |
| 4 | no-store缓存不应存储有关客户端请求或服务器响应的任何内容。 |
| 5 | no-transform不转换实体。 |
| 6 | must-revalidate缓存必须在使用之前验证过时文档的状态，并且不应使用过期文档。 |
| 7 | proxy-revalidate proxy-revalidate指令与must-revalidate指令具有相同的含义，但它不适用于非共享用户代理缓存。 |
| 8 | max-age = seconds表示客户端愿意接受年龄不大于指定时间（秒）的响应。 |
| 9 | s-maxage = seconds此指令指定的最大年龄将覆盖max-age指令或Expires标头指定的最大期限。 私有缓存始终忽略s-maxage指令。 |
HTTP - URL Encoding
HTTP URL只能使用ASCII character-set通过Internet发送，该character-set通常包含ASCII集之外的字符。 所以这些不安全的字符必须替换为%后跟两个十六进制数字。
下表显示了字符的ASCII符号及其相等的符号，最后是它的替换，可以在将URL传递给服务器之前在URL中使用:
| ASCII | 符号 | 替换 |
|---|---|---|
| <32 | 用％xx编码，其中xx是字符的十六进制表示。 | |
| 32 | space | + 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 |
| 48 | 0 | 0 |
| 49 | 1 | 1 |
| 50 | 2 | 2 |
| 51 | 3 | 3 |
| 52 | 4 | 4 |
| 53 | 5 | 5 |
| 54 | 6 | 6 |
| 55 | 7 | 7 |
| 56 | 8 | 8 |
| 57 | 9 | 9 |
| 58 | : | %3A |
| 59 | ; | %3B |
| 60 | < | %3C |
| 61 | = | %3D |
| 62 | > | %3E |
| 63 | ? | %3F |
| 64 | @ | %40 |
| 65 | A | A |
| 66 | B | B |
| 67 | C | C |
| 68 | D | D |
| 69 | E | E |
| 70 | F | F |
| 71 | G | G |
| 72 | H | H |
| 73 | I | I |
| 74 | J | J |
| 75 | K | K |
| 76 | L | L |
| 77 | M | M |
| 78 | N | N |
| 79 | O | O |
| 80 | P | P |
| 81 | Q | Q |
| 82 | R | R |
| 83 | S | S |
| 84 | T | T |
| 85 | U | U |
| 86 | V | V |
| 87 | W | W |
| 88 | X | X |
| 89 | Y | Y |
| 90 | Z | Z |
| 91 | [ | %5B |
| 92 | \ | %5C |
| 93 | ] | %5D |
| 94 | ^ | %5E |
| 95 | _ | _ |
| 96 | ` | %60 |
| 97 | a | a |
| 98 | b | b |
| 99 | c | c |
| 100 | d | d |
| 101 | e | e |
| 102 | f | f |
| 103 | g | g |
| 104 | h | h |
| 105 | i | i |
| 106 | j | j |
| 107 | k | k |
| 108 | l | l |
| 109 | m | m |
| 110 | n | n |
| 111 | o | o |
| 112 | p | p |
| 113 | q | q |
| 114 | r | r |
| 115 | s | s |
| 116 | t | t |
| 117 | u | u |
| 118 | v | v |
| 119 | w | w |
| 120 | x | x |
| 121 | y | y |
| 122 | z | z |
| 123 | { | %7B |
| 124 | | | %7C |
| 125 | } | %7D |
| 126 | ~ | %7E |
| 127 | %7F | |
| > 127 | 用％xx编码，其中xx是字符的十六进制表示 |
HTTP - Security
HTTP用于通过Internet进行通信，因此应用程序开发人员，信息提供者和用户应该了解HTTP/1.1中的安全限制。 此讨论不包括此处提到的问题的最终解决方案，但它确实提出了一些降低安全风险的建议。
个人信息泄露
HTTP客户端通常可以访问大量个人信息，例如用户的姓名，位置，邮件地址，密码，加密密钥等。因此，您应该非常小心地防止通过HTTP协议将此信息无意泄漏到其他来源。
所有机密信息都应以加密形式存储在服务器端。
显示服务器的特定软件版本可能会使服务器机器更容易受到已知包含安全漏洞的软件的攻击。
通过网络防火墙充当门户的代理应该采取特殊的预防措施来传输标识防火墙后面的主机的标头信息。
“发件人”字段中发送的信息可能与用户的隐私权益或其站点的安全策略冲突，因此，如果用户无法禁用，启用和修改该字段的内容，则不应传输该信息。
如果引用页面是使用安全协议传输的，则客户端不应在（非安全）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 - Message Examples
例子1 (Example 1)
HTTP请求从iowiki.com运行的Web服务器获取hello.htm页面
客户要求
GET /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.iowiki.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 (Example 2)
HTTP请求获取t.html页面，该页面在iowiki.com运行的Web服务器上不存在
客户要求
GET /<b class="notranslate">t.html</b> HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.iowiki.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 (Example 3)
HTTP请求从iowiki.com运行的Web服务器获取hello.htm页面，但请求的HTTP版本错误:
客户要求
GET /hello.htm <b class="notranslate">HTTP1</b>
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.iowiki.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 (Example 4)
HTTP请求将表单数据发布到在iowiki.com上运行的Web服务器上的process.cgi CGI页面。 服务器在将它们设置为cookie后返回传递的名称:
客户要求
POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.iowiki.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=iowiki.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>
