3 协议参数
3.1 HTTP版本
HTTP使用一个“<major>.<minor>”数字模式来指明协 议的版本号。协议的版本号是为了让发送端指明消息的格式和它的能力，这是为了进一步的HTTP通信，而不仅仅是获得通信的特征。协议版本是不需要修改的， 当消息组件的增加不会影响通信行为或着只增加了扩展的域值。<minor>数字是递增的，当协议会因为添加一些特征而做了修改的时候。但这些 变化不会影响通常的消息解析算法，但是它会给消息添加语意（semantic）并且会暗示发送者具有额外的能力。<major>数字也是不断 递增的，当协议的消息格式每次发生变化时。

HTTP消息的版本在HTTP-Version域被指明，HTTP-Version域在消息的第一行中。

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

注意major和minor数字必须被看成两个独立整数，每个整数都可以递增，并且可以增大到大于一位数的整数，如HTTP/2.4比HTTP/2.13低，而HTTP/2.4又比HTTP/12.3低。前导0必须被接收者忽略并且不能被发送者发送。

一个应用程序发送请求或响应消息，如果请求或响应消息里的HTTP-Version是”HTTP/1.1”，那么此应用程序必须条件遵循此协议规 范。最少条件遵循此规范的应用程序应该把”HTTP/1.1”包含在他们的消息里，并且对任何不兼容HTTP/1.1的消息必须这么做。关于何时发送特定 的HTTP-Version值的细节，参见RFC2145。

应用程序的HTTP版本是应用程序最少条件遵循的最高HTTP版本。

代理（proxy）和网关（gateway）应用程序需要被仔细对待，当转发（forwarding）消息的协议版本不同于代理或网关应用程序的协 议版本。因为消息里协议版本说明了发送者处理协议的能力，所以一个代理/网关千万不要发送一个高于该代理/网关应用程序协议版本的消息。如果代理或网关接 收了一个更高版本的消息，它也必须要降低请求的版本，要么以一个错误响应，要么切换到隧道行为（tunnel behavior）。

由于自从RFC 2068[33]发布后，产生了与HTTP/1.0代理（proxy）的互操作问题，所以缓存代理（caching proxy）必须能改变请求（request），使请求能到达他们能支持的最高版本，但网关（gateway）可以这么做也可以不这么做，而tunnel 不能这么做。代理（Proxy）/网关（gateway）的响应（Response）必须和请求（request）的HTTP版本的major数字相同。

注意：在HTTP版本间的转换可能包含头域（header field）的改变，而这些改变会可能会根据HTTP版本而被要求或被拒绝。

3.2 统一资源标识符（URI）
URIs的许多名字已为人所知：WWW地址，通用文档标识符，通用资源标识符[3]，以及后来的统一资源定位器（URL）[4]和统一资源名称（URN）[20]。就HTTP而言，统一资源定位器只是格式化的字符串，它通过名称，地址，或任何别的特征识别资源。

3.2.1一般语法
根据使用的背景，HTTP里的URI可以表示成绝对（absoulute）形式或相对形式（相对于已知的URL）。两种 形式的区别是根据这样的事实：绝对URI总是以一个方案（scheme）名作为开头，其后是一个冒号。关于URL更详尽的信息请参看"统一资源标识符 （URI）:一般语法和语义"，RFC 2396 [42]（代替了RFCs 1738 [4]和RFC 1808 [11]）。本规范采用了RFC 2396里的"URI- reference"，"absoluteURI"，"relativeURI"，"port"，"host"，"abs_path"，"rel_path", 和"authority"的定义格式。

HTTP协议不对URI的长度作事先的限制，服务器必须能够处理它们资源的URI，并且应该能够处理无限长度的URI，这种无效长度的URL可能会 在客户端以GET形式的请求产生。服务器应该返回414状态码（此状态码代表Request-URI太长），如果服务器不能处理太长的URI的时候。

注:服务器在依赖大于255字节的URI时应谨慎，因为一些旧的客户或代理实现可能不支持这些长度。

3.2.2 http URL
通过HTTP协议，http方案（http scheme）被用于定位网络资源（resourse）的位置。本节定义了这种方案的语法和语义。

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

如果端口为空或未给出，就假定为80。语义即：已识别的资源放在服务器上，在那台主机的那个端口上监听TCP连接。这时资源的请求的URI为绝对路 径（5.1.2节）。无论什么可能的时候，URL里使用IP地址都是应该避免的（参看RFC 1900 [24]）。如果绝对地址（abs_path）没有出现在URL里，那么应该给出"/"。如果代理（proxy）收到一个主机（host）名，但是这个主 机名不是全称的域名（fully quanlified domain name），则代理应该把它的域名加到主机名上。如果代理（proxy）接收了一个全称的域名，代理不必改变主机。

3.2.3 URI 比较
当比较两个URI是否匹配时，客户应该对整个URI比较时应该区分大小写，并且一个字节一个字节的比较。 但下面有些特殊情况：

- 一个为空或未给定的端口等同于URI-refernece（见RFC 2396）里的默认端口;

- 主机（host）名的比较必须不必分大小写;

- 方案（scheme）名的比较必须是不区分大小写的;

- 一个空绝对路径（abs_path）等同于"/"。

除了"保留（reserved）"和"不安全（unsafe）"字符集里的字符（参见RFC 2396 [42]） ，其它字符都等效于它们的"%HEXHEX"编码.  

例如,以下三个URI是等同的:

      http://abc.com:80/~smith/home.html

      http://ABC.com/%7Esmith/home.html

      http://ABC.com:/%7esmith/home.html

3.3 日期/时间格式（Date/Time Formats）
3.3.1完整日期 （Full Date）
 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

第一种格式是作为Internet标准提出来的，它是一个国定长度的，由RFC 1123 [8]（RFC 822[9]的升级版本）定义的一个子集。第二种格式使用比较普遍，但是基于废弃的RFC 850 [12]，并且没有年份。如果HTTP/1.1客户端和服务器解析日期，他们必须能接收所有三种格式（为了兼容HTTP/1.0），但是它们只能产生 RFC 1123里定义的日期格式来填充头域（header field）用到日期的地方。

注:日期值的接收者被鼓励能健壮的接收可能由非HTTP应用发来的日期值，例如有时可以通过代理（proxy）/网关（gateway）向SMTP或NNTP获得或转发消息。

所有的HTTP日期/时间都必须以格林威治时间（GMT）表示。对HTTP而言，GMT完全等同于UTC（世界协调时间）。前两种日期/时间格式里 包含“GMT”，它是时区的三个字面的简写，并且当读到一个asctime格式时必须先被假定是GMT时间。HTTP日期（HTTP-date）区分大小 写，不能包含一个额外的LWS，除非此LWS作为在下面的Http-date语法中指定的SP。

       HTTP-date    = rfc1123-date | rfc850-date | asctime-date

       rfc1123-date = wkday "," SP date1 SP time SP "GMT"

       rfc850-date = weekday "," SP date2 SP time SP "GMT"

       asctime-date = wkday SP date3 SP time SP 4DIGIT

       date1        = 2DIGIT SP month SP 4DIGIT

                      ; day month year （e.g., 02 Jun 1982）

       date2        = 2DIGIT "-" month "-" 2DIGIT

                      ; day-month-year （e.g., 02-Jun-82）

       date3        = month SP （ 2DIGIT | （ SP 1DIGIT ））

                      ; month day （e.g., Jun 2）

       time         = 2DIGIT ":" 2DIGIT ":" 2DIGIT

                      ; 00:00:00 - 23:59:59

       wkday        = "Mon" | "Tue" | "Wed"

                    | "Thu" | "Fri" | "Sat" | "Sun"

       weekday      = "Monday" | "Tuesday" | "Wednesday"

                    | "Thursday" | "Friday" | "Saturday" | "Sunday"

       month        = "Jan" | "Feb" | "Mar" | "Apr"

                    | "May" | "Jun" | "Jul" | "Aug"

                    | "Sep" | "Oct" | "Nov" | "Dec"

注意:HTTP对日期/时间格式的要求仅仅应用在协议的消息（译注:原文是protocol stream，便于理解这里译作消息）里。客户和服务器不必把这种格式应用于用户呈现（user presentation），请求记录日志，等等。.

3.3.2 Delta Seconds
 一些HTTP头域（header field）允许用整数秒表示时间值，整数秒用十进制表示，此整数秒表示消息被接收后时间。

   delta-seconds = 1*DIGIT

3.4 字符集
 HTTP使用术语"字符集"的定义，这和MIME中所描述的是一样.

本文档中的术语"字符集"涉及到一种方法，此方法是用一个或多个表将一个节序列转换成一个字符序列（译注：从这里来看，这应该是一种映射关系，表保 存了映射关系）。注意反方向的无条件转换（译注:从一个字符序列到一个字节序列的转换）是不需要的，因为并不是所有的字符都能在一个给定的字符集里得到， 一个字符集可能提供多个字节序列表征一个特定的字符。这个定义是为了允许不同种类的字符编码从单一简单表映射（如US-ASCII）到复杂表的转换方法如 ISO-2022技术用到的。然而，与MIME字符集名字相关的定义必须要充分说明从字节到字符的映射。特别的，使用外部轮廓信息来精确确定映射是不允许 的.

注:这里使用的术语"字符集"一般的被称作一种"字符编码"。不过既然HTTP和MIME在同一机构注册，术语统一是很重要的。

HTTP字符集是用不区分大小写的标记（token）表示。所有的标记集由IANA字符集注册机构[19]定义。

       charset = token

尽管HTTP允许用任意标记（token）作为字符集（charset）值，但任何标记值如果它已经在IANA字符集注册机构注册了则必须表示在该注册机构定义的字符集。对那些非IANA定义的字符集，应用程序应该限制使用。

HTTP协议的实现者应该注意IETF字符集的要求[38][41].

3.4.1丢失的字符集（Missing Charset）
一些HTTP/1.0应用程序当他们解析Content-Type头时，当发现 没有字符集参数（charset parameter，译注:Content-Type: text/plain; charset=UTF-8，此时charset=UTF-8就是字符集参数）可用时，这意味着接收者必须猜测实体主体（entity body，译注：这里翻译成“实体主体”因为Content-Type头是实体头，消息头可以分为实体头，常用头，请求头，响应头，在译文中多次用到 “头”和“头域”，如消息头，消息头域，其实是同一个意思，HTTP1.1协议有时候概念并不是完全统一的）的字符集是什么。如果发送者希望避免这种情 况，他应该在Content-Type头域里包含一个字符集参数，即使字符集是ISO-8859-1也应该这样做，这样就不会让接收者产生混淆。

不幸的是，一些旧的HTTP/1.0客户端不能处理在Content-Type头域里明确指定的字符集参数。HTTP/1.1接收端必须要认真对待 发送者提供的字符集；并且当用户代理（user agent，译注：如浏览器，可认为是接收端）开始显示一个文档时，虽然用户代理可以猜测文档的字符集，但如果content-type头域里提供了字符 集，并且用户代理也支持这种字符集的显示，不管用户代理是否愿意，它必须要利用这种字符集。参见3.7.1节。

3.5 内容编码（Content Codings）
内容编码值（content coding value）表示一种已经或可以应用于实体的编码转换（encoding   transformation）。内容编码主要用于文档的压缩或其它有效的变换，但这种变换需要不能丢失文档的媒体类型（media type，译注：文档一般会有媒体类型，这通过在content-type里指定）的特性，也不能丢失文档的信息（译注：就像有损压缩和无损压缩，前者不 会丢失信息，后者会丢失信息）。实体经常被编码的储存，然后直接传送，接收端只能解码。

       content-coding   = token

所有内容编码值（content-coding value）是不区分大小写的。HTTP/1.1在接收译码 （14.3节）和内容译码（Content-Encoding）（14.11节）头域里使用内容编码值（content-coding value）。尽管该值描述了内容编码，更重要的是它指出了一种解码机制，利用这种机制对实体的编码进行解码。

网络分配数字权威（ （IANA）充当内容编码值标记（token）的注册机构。最初，注册表里包含下列标记:

gzip（压缩程序）

一种由文件压缩程序"gzip"（GNU zip）产生的编码格式（在RFC 1952中描述）。这种编码格式是一种具有32位CRC的Lempel-Ziv编码（LZ77）。

compress（压缩）

一种由UNIX文件压缩程序"compress"产生的编码格式。这种编码格式是一种具有可适应性的Lempel-Ziv-Welch编码（LZW）。

对于将来的编码，用程序名识表征编码格式是不可取。在这里用到他们是因为他们在历史的作用，虽然这样做并不好。为了同以前的HTTP实现相兼容，应用程序应该将"x-gzip"和"x-compress"分别等同于"gzip"和"compress"。

deflate（缩小）　

deflate编码是由RFC 1950 [31]定义的"zlib"编码格式与RFC 1951 [29]里描述的"deflate"压缩机制的组合的产物。

identity（一致性）

 Identity是缺省编码；指明这种编码表明不进行任何编码转换。这种内容编码仅被用于接收译码（Accept-Encoding）头域，但不能被用在内容译码（Content-Encoding）头域。.

 新的内容编码值标记（token）应该被注册；为了实现客户和服务器间的互操作性，实现新值的内容编码算法规范应该能公开利用并且能独立实现，并且与本节中被定义的内容编码目的相一致。

3.6 传输编码 （Transfer Codings）
传输编码值（transfer-coding value，译注：transfer coding和和transfer-coding这两个术语在本协议规范里所表达的意思其实没什么太大区别，“transfer-coding”可能更能 表达语意，因为它是规则中的规则名，见下面红字的规则）被用来表示一个已经，能够，或可能应用于一个实体的编码转换，传输编码是为了能够确保网络安全传 输。这不同于内容编码（content coding），因为传输编码（transfer coding）是消息的属性而不是实体的属性。

       transfer-coding = "chunked" | transfer-extension

       transfer-extension      = token *（ ";" parameter ）

   参数（parameter）采用属性/值对的形式.

       parameter                    = attribute "=" value

       attribute                   = token

       value                     = token |   quoted-string

所有传输编码值（transfer-coding value，译注：上面红体字等号右边规则表达式所表达的值）是大小写不敏感。传输编码值在TE头域（14.39节）和在传输译码（Transfer-encoding） 头域中（14.41节）被运用。

无论何时，传输编码（transfer-coding）应用于一个消息主体（message body）时，如果存在多个传输编码，则这些传输编码中必须包括“块”（"chunked"）传输编码，除非通过关闭连接而中断消息。当“块” （“chunked”）传输编码被用于传输编码时，它必须是应用于消息主体的最后传输编码。"块"（"chunked"）传输编码最多只能用于消息主体 （message-body）一次。规定了上述规则后，接收者就可以确定消息的传输长度（transfer-length）（4.4节）

传输编码与MIME[7]的内容传输译码（Content-Transfer-Encoding，译注：transfer应该是转移，迁移的意思， 又例如HTTP协议，应该翻译成“超文本转移协议”，但是历史上都翻译成“超文本传输协议”，所以这里翻译成“超文本传输协议”）值有相类似型，它被定义 能够实现在7位传输服务上保证二进制数据的传输安全。不过，传输编码与内容传输译码（Content-Transfer-Encoding）对纯8位传输 协议有不同的关注点。在HTTP中，消息主体存在不安全的隐患，因为有时候很难确定消息主体的长度，在共享的传输上加密数据也会带来安全性问题 （7.2.2节）。

网络分配数字权威（IANA）担任注册传输编码值标（token）记的角色。起初,注册包含如下标记:"块"（3.6.1节）,"身份"（3.6.2节）,"gzip"（3.5节）,"压缩"（3.5节）,和"缩小"（3.5节）.

新的传输编码值标记应该注册，这同新的内容编码值标记也需要注册一样。.

接收端接收到一个带有传输编码（transfer-coding）（译注：通过消息头域transfer-encoding指明此实体主体的传输编 码）的实体主体（entity body），如果它不能对这个编码后的实体主体进行解码，那么它应返回501（不能实现），并且要切断联系。服务器不能向HTTP/1.0客户发送传输编 码.

3.6.1块传输编码（Chunked Transfer Coding）
块编码（chunked encoding）改变消息主体使消息主体（message body，译注：消息主体与实体主体是有区别的，后面章节将会介绍）成块发送。每一个块有它自己的大小（size）指示器，在所有的块之后会紧接着一个可 选的包含实体头域的尾部（trailer）。这允许发送端能动态生成内容，并能携带有用的信息，这些信息能让接收者判断消息是否接收完整。

       Chunked-Body（块正文）   = *chunk（块）

                                 last-chunk（最后块）

                                    trailer（尾部）

                             CRLF

       chunk（块）          = chunk-size [ chunk-extension ] CRLF

                               chunk-data CRLF

       chunk-size     = 1*HEX

       last-chunk     = 1*（"0"） [ chunk-extension ] CRLF      

       chunk-extension= *（ ";" chunk-ext-name [ "=" chunk-ext-val ] ）             

       chunk-ext-name = token

       chunk-ext-val = token | quoted-string

       chunk-data     = chunk-size（OCTET）

       trailer        = *（entity-header CRLF）

chunk-size是用16 进制数字字符串。块编码（chunked encoding）以任一大小为0的块结束，紧接着是尾部（trailer），尾部以一个空行终止。

尾部（trailer）允许发送端在消息的末尾包含附加的HTTP头域（header field）。Trailer头域（Trailer header field，译注：Trailer头是常用消息头，在14.40节说明）被应用来指明哪些头域被包含在块编码的尾部（trailer） （见14.40节）

如果服务器要用块传输编码进行响应，它不能包含尾部（trailer），除非以下至少一条为真：

a）如果此响应的请求包括一个TE头域，并且它指明了传输编码中的“trailers”是可接受的，当响应的传输编码（transfer-coding）是块编码时。这在14.39节中描述；或者

 b）如果服务器是响应的源服务器，并且接收端接收块传输编码响应但不会去理会响应的尾部（trailer，译注：尾部包含头域，头域就是消息的元 数据（metadata））并且这种方式源服务器是可以接受的，这时服务器是不需要把尾部（trailer）包含进消息的块传输编码中去的。换句话说，源 服务器原意接受尾部（trailer）可能会在到达客户端时被丢弃的可能性。

此要求防止了一种互操作性的失败，当消息被一个HTTP/1.1（或更迟的）代理（proxy）接收并且转到一个HTTP/1.0的接收端的时候。  

在附录19.4.6节介绍了一个例子，这个例子介绍怎样对一个块正文（chunked-body）进行解码。

所有HTTP/1.1应用程序必须能接收和解码块（chunked）传输译码，并且必须忽略它们不能理解的块扩展（chunk-extentsion，译注：见上面的规则表达式）.

3.7 媒体类型（Media Type）
HTTP在Content-Type（14.17节）实体头域和Accept请求头域里利用网络媒体[17]类型，这是为了提供公开的，可扩展的数据打印和类型协商。

media-type    = type "/" subtype *（ ";" parameter ）

type               = token

subtype         = token

 

参数（parameter）以一种属性/值对的形式跟随type/subtype（如3.6节定义） 。

类型（type），子类型（subtype），和参数（parameter）里属性名称是大小写不敏感的。参数值有可能是大小写敏感的，也可能不 是，这根据参数里属性名的语意。线性空白（LWS）不能被用于类型（type）和子类型（subtype）之间，也不能用于参数的属性和值之间。参数的出 现或不出现对处理媒体类型（media-type）可能会有帮助，这取决于它在媒体类型注册表里的定义。

注意一些旧的HTTP应用程序不能识别媒体类型的参数（parameter）。当向一个旧的HTTP应用程序发送数据时，发送端只有在被type/subtype定义需要时才使用类型参数（parameter）。

媒体类型（media-type）值需要被注册到网络数字分配权威（IANA[19]）里。媒体类型的注册程序在RFC 1590[17]中大概描述。使用未经注册的媒体类型是不被鼓励的。

 

3.7.1规范化和文本缺省 （Canonicalization and Text Defaults）
网络媒体类型以规范化的格式被注册。一个实体主体（entity-body）通过HTTP消息传输，它必须在传输前以一种合适的规范化的格式表征除了文本类型（text type），文本类型将会在下一段阐述。

当消息以一种规范化的格式表现时，文本类型的子类型（subtype）运用GRLF作为文本里的换行符。HTTP放松了这个要求，并且允许文本媒体 以一个CR或LF代表一个换行符传输，并且这样做要贯穿整个实体主体（entity-body）。HTTP应用程序必须能接收CRLF，CR和LF作为在 文本媒体一个换行符。另外，如果文本字符集（character set）不能用字节13和10来分别地表征CR和LF因为存在一些多字节字符，HTTP允许应用字符集里等价于CR和LF的字节序列来表示换行符。对换行 符的灵活处理只能应用于实体主体里的文本媒体；在HTTP消息结构里，一个单独的CR或LF都不能代替CRLF（如头域和多边界体（multipart boundaries）结构里）。

如果一个实体主体（entity-body）用内容编码（content-coding）进行编码，原始数据（译注：被编码前的数据）在被编码前必须是一种定义的媒体类型格式。.

"charset"参数（parameter）被应用于一些媒体类型，来定义数据的字符集（见3.4节）。当发送者没有在媒体类型（media- type）里指明charset参数（parameter）时，文本类型的子媒体类型（subtype）被认为是缺省的ISO-8859-1字符集当被接 收者接收后。数据必须被合适的字符集标识。3.4.1节描述了兼容性问题。

 

3.7.2多部分类型（Multipart type）
MIME提供了一系列"多部分"类型---在单个消息主体内包装一个或多个实体。 所有的多部分类型共享一个公共的语法（这在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用户代理一样的或者相似的行为，这依赖于接收何种多部分 类型。一个多部分类型消息的每一个体部分（bady-part）里的MIME头域对于HTTP并没有太大意义除了MIME语意。

通常， 一个HTTP用户代理应该遵循与一个MINE用户代理相同或相似。如果一个应用程序收到一个不能识别的多部分子类型，这个应用程序必须将它视为"multipart/mixed"。

注:"multipart/form-data"类型已经被规范的定义为传送窗体数据（译注：一般用窗体上传数据时，上传的数据类型就是为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被设计允许应用程序实现不依靠有关对范围的了解。