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被设计允许应用程序实现不依靠有关对范围的了解。