HTTP/1.1协议详解与修订版

需积分: 16 158 浏览量更新于2024-07-24 收藏 881KB PDF 举报

"这是一个关于HTTP协议的中文翻译版，主要涵盖了HTTP/1.1的规范，由孙超进翻译，详细解释了HTTP协议的用途、特点和历史演变，旨在为分布式超媒体信息系统提供通信标准。" 在互联网技术领域，HTTP（超文本传输协议）是应用层最常用的一种协议，用于在客户端和服务器之间交换超媒体信息，如网页内容。HTTP/1.1是HTTP协议的第1.1个版本，是对RFC2068的修订，旨在解决HTTP/1.0中存在的一些问题和不足。 HTTP/1.1协议的核心特性包括： 1. **无状态**：每个HTTP请求都是独立的，服务器不会记住之前请求的状态，这样可以减轻服务器的负担，但同时也需要通过Cookie或其他机制来管理会话状态。 2. **可扩展性**：HTTP协议允许通过扩展其请求方法（如GET、POST、PUT等）、错误代码和消息头来适应不同的应用场景。 3. **数据表现形式的定义与协商**：HTTP允许定义和协商数据的表示方式，这使得系统可以独立于数据传输方式构建，例如通过Content-Type头来指定数据类型。 4. **面向应用层**：HTTP设计时考虑了分布式和协作的超媒体信息系统，不仅支持信息获取，还支持搜索、终端更新和注解等功能。 HTTP/1.1相对于HTTP/1.0的改进点包括： 1. **分层代理和缓存的支持**：HTTP/1.1更好地处理了代理服务器和缓存的情况，提高了效率和响应速度。 2. **持久连接**：通过使用Keep-Alive，HTTP/1.1允许在一个TCP连接上发送多个请求和响应，减少了连接建立和关闭的开销。 3. **虚拟主机**：支持多个域名共享同一IP地址，通过Host头来区分不同的服务器。 4. **头部压缩**：HTTP/1.1引入了Chunked编码，可以分块传输数据，方便处理大文件和流媒体。 5. **错误处理**：增加了更多的错误状态码，使错误反馈更加精确。 6. **更好的性能优化**：如预读取、管道连接等机制，提升了网络性能。 HTTP/1.1的使用非常广泛，是Web开发中的基础，它与HTML、CSS、JavaScript等技术共同构成了现代Web应用的基础。理解HTTP协议的工作原理对于开发者来说至关重要，因为它直接影响到网页的加载速度、交互性能以及安全性。无论是前端开发、后端开发还是网络运维人员，都需要对HTTP/1.1有深入的理解，以便优化网络通信，提高用户体验。

3.7.2 多部分类型（Multipart type）

MIME 提供了一系列“多部分”（multipart）类型---在单个消息主体内包装一个或多个实体。所

有的多部分类型共享一个公共的语法（这在 RFC 2046[40]的 5.1.1 节中描述），并且包含一个

边界（boundary）参数作为多部分媒体类型的值的一部分。多部分类型的消息主体是一个协议

元素，并且必须用 CRLF 来标识体部分（body-part，译注：见 RFC 2046 的 5 节）之间的换行。

不同于 RFC 2046 里的多部分消息类型的描述，HTTP1.1 规定任何多部分类型的消息尾声

（epilogue，译：见 RFC 2046 对多部分消息类型的规则描述）必须不能存在；HTTP 应用程

序不能传输尾声（epilogue）（即使原始的多部分消息尾部包含一个尾声）。存在这些限制是

为了保护多部分消息主体的自我定界的特性，因为多部分边界的结束（译注：根据 RFC2046

中定义，多部分边界结束后可能还会有尾声）标志着消息主体的结束。

通常，HTTP 把一个多部分类型的消息主体（message-body）和任何其它媒体类型的消息主

体等同对待：严格看作有用的负载体。有一个例外就是“ multipart/byterange”类型（附录

19.2），当它出现在 206（部分内容）响应时，此响应会被一些 HTTP 缓存机制解析，缓存机

制将会在 13.5.4 节和 14.16 节介绍。在其它情况下，一个 HTTP 用户代理会遵循 MIME 用户代

理一样或者相似的行为，这依赖于接收何种多部分类型。一个多部分类型消息的每一个体部分

（body-part）里的 MIME 头域对于 HTTP 除了 MIME 语意并没有太大意义。

通常，一个 HTTP 用户代理应该遵循与一个 MIME 用户代理相同或相似的行为。如果一个应用

程序收到一个不能识别的多部分子类型，这个应用程序必须将它视为"multipart/mixed"。

注："multipart/form-data"类型已经被特别地定义用来处理 Post 请求方法传送的窗体数据，这

在 RFC 1867[15]里定义。

3.8 产品标记（product Tokens）

产品标记用于使通信应用软件能通过软件名称和版本来标识自己。很多头域都会利用产品标记，

这些头域允许构成应用程序重要部分的子产品能以空白分隔去列举。通常为了识别应用程序，

产品以应用程序的重要性的顺序来列举的。

product = token ["/" product-version]

product-version = token

例:

User-Agent:CERN-LineMode/2.15 libwww/2.17b3

Server: Apache/0.8.4

产品标记应言简意赅。它们不能用来做广告或其他不重要的信息。虽然任一标记可能出现

product-version 里，但这个标记仅能用来做一个版本（i.e., 同产品中的后续版本应该在

product-version 上有区别）

3.9 质量值（Quality Values）

HTTP 内容协商（content negotiation，12 节介绍）运用短“浮点”数字（short floating point

number）来表示不同协商参数的相对重要性。重要性的权值被规范化成一个从 0 到 1 的实数。0

是最小值，1 是最大值。如果一个参数的质量值（quanlity value）为 0，那么这个参数的内容对

客户端来说是不被接受。HTTP/1.1 应用程序不能产生多于三位小数的实数。下面规则限定了这

些值。

qvalue = （ "0" [ "." 0*3DIGIT ] ）

| （ "1" [ "." 0*3（"0"） ] ）

"质量值" 是一个不当的用词，因为这些值仅仅表示相对等级。

3.10 语言标签（Language Tags）

一个语言标签表征一种自然语言，这种自然语言能说，能写，或者被用来人与人之间的沟通。

计算机语言明显不包括在内的。HTTP 在 Accept-Language 和 Content-Language 头域里应用

到语言标签（language tag）。

HTTP 语言标签的语法和注册和 RFC 1766[1]中定义的一样。总之，一个语言标签是由一个部分

或多部分构成：一个主语言标签和可能为空的多个子标签。

Language-tag = primary-tag*（"-" subtag）

primary = 1*8ALPHA

subtag = 1*8ALPHA

标签中不允许出现空格，标签大小写不敏感（case-insensitive）。由 IANA 来管理语言标签中

的名字。典型的标签包括:

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

上面的任意两个字母的主标签是一个 ISO-639 语言的缩写，并且两个大写字母的子标签是一个

ISO-3166 的国家代码。（上面的最后三个标签是未经注册的标签；但是除最后一个之外所有的

标签都会将来注册）。

3.11 实体标签（Entity Tags）

实体标签被用于比较相同请求资源中两个或更多实体。HTTP/1.1 在 ETag（14.19 节），If-

match（14.24 节），If-None-match（14.26 节）和 If-Rang（14.27 节）头域中运用实体标签。

关于它们怎样被当作一个缓存验证器（cache validator）被使用和比较在 13.3.3 节被定义。一

个实体标签由一个给定的晦涩引用字符串（opaque quoted string），还可能前面带一个弱指

示器组成。

entity-tag = [ weak ] opaque-tag

weak = "W/"

opaque-tag = quoted-string

一个“强实体标签”如果被一个资源的两个实体里共享，那么这两个实体必须在字节上等价。

一个“弱实体标签”是以"W/"前缀的，它可能会被一个资源的两个实体共享，如果这两个实体

是等价的，并且能彼此替换，并且替换后也不会在语义上发生太大改变。一个弱实体标签只能

用于弱比较（weak comparison）。

在一个特定资源的所有实体版本里，一个实体标签必须能唯一。一个给定的实体标签值可以被

用于不同的 URI 请求的实体。相同实体标签的值应用于不同 URI 请求的实体，并不意味着这些

实体是等价的。

3.12 范围单位（Range Units）

HTTP/1.1 允许客户请求响应实体的一部分。 HTTP/1.1 在 Range（14.35 节）和 Content-

Range（14.16 节）头域里应用范围单位（range units）。任何实体根据不同结构化单元都能被

分解成子范围

range-unit = bytes-unit | other-range-unit

bytes-unit = "bytes"

other-range-unit = token

HTTP/1.1 中定义的唯一的范围单位是"bytes"。HTTP/1.1 实现可能忽略其他单位指定的范围。

HTTP/1.1 被设计允许应用程序实现不依赖于对范围的了解。

4 HTTP 消息

4.1 消息类型（Message Types）

HTTP 消息由从客户到服务器的请求消息和从服务器到客户的响应消息两部分组成.

HTTP-message = Request|Response ;HTTP/1.1

请求（第 5 节）和响应（第 6 节）消息利用 RFC 822[9]定义的常用消息的格式，这种消息格式

是用于传输实体（消息的负载）。两种类型的消息都由一个开始行（start-line），零个或更多

个头域（经常被称作“头”），一个指示头域结束的空行（也就是以一个 CRLF 为前缀的什么

也没有的行），最后一个可有可无的消息主体（message-body）组成。

generic-message = start-line

*（message-header CRLF）

CRLF

[ message-body ]

start-line = Request-Line | Status-Line

为了健壮性，服务器应该忽略任意请求行（Request-Line）前面的空行。换句话说，如果服务

器开始读消息流的时候发现了一个 CRLF，它应该忽略这个 CRLF。

一般一个存在问题的 HTTP/1.0 客户端会在 POST 请求消息之后添加额外的 CRLF。为了重新声

明被 BNF 明确禁止的行为，一个 HTTP/1.1 客户端不能在请求前和请求后附加一些不必要的

CRLF。

4.2 消息头（Message Headers）

HTTP 头域包括常用头域（4.5 节），请求头域（5.3 节），响应头域（6.2 节）和实体头域

（7.1 节）。它们遵循的是 RFC822[0]3.1 节中给出的同一个常用格式。每一个头域由一个名字

（域名）跟随一个":"和域值构成。域名是大小写不敏感的。域值前面可能有任意数量的 LWS 的。

但 SP（空格）是首选的。头域能被延伸多行，这通过在这些行前面加一些 SP 或 HT。应用程序

当产生 HTTP 消息时，应该遵循“常用格式”，因为可能存在一些应用程序，他们不能接收任

何常用形式之外的形式。.

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

field-name = token

field-value = *（ field-content | LWS ）

field-content = <the OCTETs making up the field-value

and consisting of either *TEXT or combinations

of token, separators, and quoted-string>

filed-content 不包括任何前导或后续的 LWS（线性空白）：线性空白出现在域值（ filed-

value）的第一个非空白字符之前或最后一个非空白字符之后。前导或后续 LWS 可能会在不会

改变域值语意情况下被删除。任何出现在 filed-content 之间的 LWS 可能在解析域值之前或把这

个消息往下流传递时会被一个 SP 代替。.

不同域名的头域被接收的顺序是不重要的。然而，首先发送常用头域，然后紧接着是请求头域

或者是响应头域，然后是以实体头域结束，这样做是一个好的的方法。

如果一个头域的域值被定义成一个以逗号隔开的列表，那么使用同一个域名（filed-name）的

多个消息头域可能会出现在一些消息中。不改变消息的语义，可以把相同名的多个头域结合成

一个“域名:域值”对的形式，这可以通过把每一个后续的域值加到第一个里，每一个域值用

逗号隔开的算法实现。同名头域的接收顺序对合并的域值的解释是有重要意义的，所以代理

（proxy）当把消息转发时不能改变域值的顺序。

4.3 消息主体（Message Body）

HTTP 消息的消息主体用来承载请求和响应的实体主体（ entity-body）的。这些消息主体

（message-body）仅仅当被传输译码头域（Transfer-Encoding）指明的传输编码（transfer-

coding）应用于实体主体（entity-body）时才和实体主体相区别，其它情况消息主体和实体主

体相同。传输译码头域在 14.41 节阐述。

message-body=entity-body|<entity-body encoded as per Transfer-Encoding>

传输译码头域被用来指明应用程序的传输编码，它是为了保证消息的安全和合适的传输。传输

译码（Transfer-Encoding）头域是消息的属性，而不是实体的属性，因此可能会沿着请求 /响

应链被添加或删除。（然而，3.6 节描述了一些限制当使用某个传输编码时）

什么时候消息主体（message-body）允许出现在消息中，这根据不同请求和响应来决定的。

请求中消息主体（ message-body ）的存在是被请求中消息头域中是否存在内容长度

（ Content-Length ）或传输译码（ Transfer-Encoding ）头域来通知的。一个消息主体

（message-body）不能被包含在请求里如果某种请求方法（见 5.1.1 节）不支持请求里包含实

体主体（entity-body）。一个服务器应该能阅读或再次转发请求里的消息主体；如果请求方法

不允许包含一个实体主体（entity-body），那么当服务器处理这个请求时消息主体应该被忽略。

对于响应消息，消息里是否包含消息主体依赖相应的请求方法和响应状态码。所有 HEAD 请求

方法的请求的响应消息不能包含消息主体，即使实体头域出现在请求里。所有 1XX（信息的），

204（无内容的）和 304（没有修改的）的响应都不能包括一个消息主体（message-body）。

所有其他的响应必须包括消息主体，即使它长度可能为零。

4.4 消息的长度（Message Length）

当消息主体出现在消息中时，一条消息的传输长度（transfer-length）是消息主体（message-

body）的长度；也就是说在实体主体被应用了传输编码（transfer-coding）后。当消息中出现

消息主体时，消息主体的传输长度（transfer-length）由下面（以优先权的顺序）决定：:

1。任何不能包含消息主体（message-body）的消息（这种消息如 1xx，204 和 304 响应和任

何 HEAD 方法请求的响应）总是被头域后的第一个空行（CRLF）终止，不管消息里是否存在

实体头域（entity-header fields）。

2。如果 Transfer-Encoding 头域（见 14.41 节）出现，并且它的域值是非”“dentity”传输编码

值，那么传输长度（transfer-length）被“块”（chunked）传输编码定义，除非消息因为通过

关闭连接而结束。

3。如果出现 Content-Length 头域（属于实体头域）（见 14.13 节），那么它的十进制值（以

字节表示）即代表实体主体长度（entity-length，译注：实体长度其实就是实体主体的长度，

以后把 entity-length 翻译成实体主体的长度）又代表传输长度（ transfer-length）。Content-

Length 头域不能包含在消息中，如果实体主体长度（entity-length）和传输长度（transfer-

length）两者不相等（也就是说，出现 Transfer-Encodind 头域）。如果一个消息即存在传输译

码（Transfer-Encoding）头域并且也 Content-Length 头域，后者会被忽略。

4。如果消息用到媒体类型“multipart/byteranges”，并且传输长度（transfer-length）另外也没

有指定，那么这种自我定界的媒体类型定义了传输长度（transfer-length）。这种媒体类型不能

被利用除非发送者知道接收者能怎样去解析它； HTTP1.1 客户端请求里如果出现 Range 头域

并且带有多个字节范围（byte-range）指示符，这就意味着客户端能解析 multipart/byteranges

响应。

一个 Range 请求头域可能会被一个不能理解 multipart/byteranges 的 HTTP1.0 代理（proxy）

再次转发；在这种情况下，服务器必须能利用这节的 1，3 或 5 项里定义的方法去定界此消息。

5。通过服务器关闭连接能确定消息的传输长度。（请求端不能通过关闭连接来指明请求消息体

的结束，因为这样可以让服务器没有机会继续给予响应）。

为了与 HTTP/1.0 应用程序兼容，包含 HTTP/1.1 消息主体的请求必须包括一个有效的内容长

度（Content-Length）头域，除非服务器是 HTTP/1.1 遵循的。如果一个请求包含一个消息主体

并且没有给出内容长度（Content-Length），那么服务器如果不能判断消息长度的话应该以

400 响应（错误的请求），或者以 411 响应（要求长度）如果它坚持想要收到一个有效内容长

度（Content-length）。

所有的能接收实体的 HTTP/1.1 应用程序必须能接受"chunked"的传输编码（3.6 节），因此当

消息的长度不能被提前确定时，可以利用这种机制来处理消息。

消息不能同时都包括内容长度（Content-Length）头域和非 identity 传输编码。如果消息包括了

一个非 identity 的传输编码，内容长度（Content-Length）头域必须被忽略.

当内容长度（Content-Length）头域出现在一个具有消息主体（message-body）的消息里，

它的域值必须精确匹配消息主体里字节数量。HTTP/1.1 用户代理（user agents）当接收了一个

无效的长度时必须能通知用户。

4.5 常用头域（General Header Fields）

有一些头域即适用于请求消息也适用于响应消息，但是这些头域并不适合传输实体。这些头域

只能应用于传输消息。

general-header = Cache-Control ; Section 14.9

剩余104页未读，继续阅读

Just已存在

粉丝: 30
资源: 25

HTTP/1.1协议详解与修订版

HTTP协议详解.doc

HTTP协议-中文版

HTTP协议（RFC2616）中文版.pdf

lorawan协议中文版下载

mqtt协议3.1.1中文版本

3m sip2 标准协议文档(中文版)

rfc3261(sip协议)中文版

rfc2326中文版pdf

rfc3261中文版 pdf 下载

restful web services 中文版pdf

最新资源