HTTP/1.1协议详解：从RFC2616中文版

需积分: 10 187 浏览量更新于2024-07-25 收藏 1023KB PDF 举报

"HTTP协议(RFC2616)中文版.pdf" 是一份详尽介绍HTTP/1.1协议的文档，由孙超进翻译，旨在规定互联网社区的标准协议并接受进一步的讨论和改进。该文档涵盖了HTTP协议的基本原理、设计目标、历史发展以及HTTP/1.1相对于早期版本的改进。 HTTP（超文本传输协议）是一种用于分布式、协作式超媒体信息系统的应用层协议。自1990年伴随着万维网的兴起，HTTP已经从最初的HTTP/0.9发展到HTTP/1.1，后者在RFC2068的基础上进行了修订，以应对分层代理、缓存、持久连接和虚拟主机等需求。 HTTP/1.1的特点在于其无状态性，即每次请求之间不保存任何上下文信息，这简化了协议的实现但可能需要通过额外机制（如Cookie）来管理状态。此外，HTTP允许数据以可定义的表现形式传输，这意味着不同的数据类型（如文本、图像、音频等）可以通过协商来决定适当的编码方式。这种灵活性使得HTTP不仅适用于超文本传输，还可应用于其他系统，如名称服务器和分布式对象管理系统。 HTTP/1.1相对于HTTP/1.0的改进主要包括： 1. **分层代理支持**：允许中间代理服务器转发请求和响应，以提高网络效率和安全性。 2. **缓存机制**：通过缓存响应，减少不必要的网络传输，提高性能。 3. **持久连接**：允许客户端和服务器在完成一次请求-响应交互后保持连接，减少建立新连接的开销。 4. **虚拟主机**：允许多个域名共享同一IP地址，通过Host头部来区分不同的网站。此外，HTTP/1.1引入了可扩展的方法集和消息头，增强了协议的灵活性和功能性。例如，除了基本的GET和POST方法，还可以定义新的请求方法来满足特定应用需求。消息头则提供了丰富的元信息，如内容类型、缓存控制、身份验证等，以修饰请求和响应的语义。 HTTP协议基于URI（统一资源标识符）体系，特别是URL（统一资源定位符），作为资源的唯一地址。它允许通过不同的方法（如GET、POST、PUT、DELETE等）来操作这些资源，支持用户进行浏览、提交数据、更新内容和添加注解等操作。这份HTTP协议(RFC2616)中文版是理解HTTP/1.1协议及其在互联网基础设施中作用的重要参考资料，对于开发者、网络架构师和相关IT专业人员来说具有极高的学习价值。

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页未读，继续阅读

原来就是这么简单

粉丝: 1
资源: 5

HTTP/1.1协议详解：从RFC2616中文版

Http RFC1945中文版.pdf

HTTP协议（RFC2616）中文版.pdf

RFC2328中文版.pdf

RFC3550中文版.pdf

RFC3261中文版.pdf

python023基于Python旅游景点推荐系统带vue前后端分离毕业源码案例设计.zip

基于Java的JFrame和JDBC数据库连接的小游戏合集.zip

Assimulo-3.2.1-cp36-cp36m-win32.whl.rar

IMG_20241105_235746.jpg

JSP基于SSM网上医院预约挂号系统毕业源码案例设计.zip

最新资源