RFC 3.1~3.4的中文翻译
cloudxpc
给想看的朋友参考参考，希望不会误导别人。翻译的不好，哪位发现重大错误的话就直接无视这个帖吧。另外也想添点人气，呵
3 协议参数
3.1 HTTP版本
HTTP 是用”<大版本号>.<小版本号>” (<major>.<minor>) 这种形式来表示协议的版本。之所以要规定协议版本是为了让发送方
可以指明它能够接受的信息的格式和和它具有的能力以便于让发送方可以更好的处理HTTP通信，而并不是为了指出这个版本的协议在通信过程中有哪些特性。
像信息中那部分不影响通信行为的附加成分或者只是在信息中的可扩展区域添加了一些新值，这种情况一般都不影响协议的版本号。只有当一些改动使得协议增加
了新的特性，并且这些特性没有改变原有的信息解析算法，但是这些特性可能增加了信息的含义也就意味着增强了发送方的能力，这时候小版本号<minor>
才会增加。而当协议中的信息格式发变化时，大版本号<major>才会增加。RFC 2145会有更全面的解释。
HTTP信息的版本号是定义在信息中第一行HTTP-Version这个字段中的。
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT (BNF表示形式，例如：HTTP-
Version=HTTP/1.1 )
注意大版本号和小版本号必须是两个整数数字，每个数字都可以增加到大于1位的数。如，HTTP/2.4就比HTTP/2.13小，同样比HTTP/
12.3小。数字前面的0必须被接收方忽略并且也不能发送出去。
一个应用程序发送包含HTTP-Version为HTTP/1.1的请求/响应信息时，必须要遵循此文档的规范，至少也要有条件的遵循。这个应用程序应
该把HTTP-Version=HTTP/1.1包含在它发送/接收的信息中，并且必须对不兼容HTTP/1.0的信息也这么做。关于发送HTTP-
Version的更详细信息请参见RFC 2145.
应用程序的HTTP版本是这个应用程序条件遵循的HTTP最高版本。
在信息协议版本和代理/网关协议版本不同的情况下，代理/网关程序转发信息时应格外小心。因为协议的版本指明了发送方的能力，代理/网关千万不要发送比
自己应用程序协议的实际版本高的信息。如果代理/网关接收了一个比自己协议版本高的请求，它必须降低请求的版本，或者响应一个错误，或者转换到通道
(tunnel)模式。
自从RFC 2068发布以来，发现与HTTP/1.0存在互用性问题，因此，缓存代理必须把请求升级到它支持的最高版本，网关对这个操作不是必须的但
也可以这么做，而通道(tunnel)不能这么做。代理/网关必须和请求的主版本号保持一致才能对这个请求做出响应。
注意：对HTTP版本之间的转换可能被要求或者被禁止修改信息头，取决于转换的版本。
3.2 Uniform Resource Identifiers
URI被人们所熟知是通过许多名字：WWW 地址, Universal Document Identifiers, Universal
Resource Identifiers，和后来的Uniform Resource Locators (URL) 和 Names (URN)。
就HTTP而言，URI就是简单的有格式的字符串，通过名字，位置和其它字符指向一个源。
3.2.1 一般语法
根据使用情况，URI在HTTP中可以表示为绝对形式或相对形式。两种形式的区别是，绝对形式的URI是以一个如http、https、ftp的名称后
跟一个分号开始。URL语法和含义的详细信息参见“Uniform Resource Identifiers (URI): Generic
Syntax and Semantics,” RFC 2396。本文档采用了其中的一些定义，“URI-reference”,
“absoluteURI”, relativeURI”,“port”, “host”,“abs_path”, “rel_path”,
and “authority”。
HTTP协议对URI的长度没有做限制。服务器必须能够识别任何存放在它上面的资源的URI，并且应该能够处理无限长度通过GET请求方式产生的
URI。如果一个URI的长度超过服务器所能处理的范围，那么服务器应该返回414错误(请求URI超长)。
注意：服务器对超过255字节的URI应该谨慎，因为一些较老的客户端或代理或许不能完全支持这种长度。
3.2.2 HTTP URL
“http”模式是用于通过HTTP协议去定位网络资源。这部分将解释HTTP URL的语法和含义。
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
(BNF.. 例如: http_URL=http://localhost:8080/a.jsp?id=3)
如果端口没有给出或为空，默认为80. 上面的意思就是那个指定的资源是位于正在某端口监听TCP连接的那台服务器上，而请求那个资源的
Request-URI就是后半段从abs_path开始。在任何可能的情况下都要避免在URL中使用IP地址。如果在URL中abs_path不存
在，必须给出”/”做为请求资源的Request-URI。如果一个代理接收了一个不是完整域名格式的主机名，那么它可以为这个主机名添加域名。相反如
果代理接收了一个完整的域名，那么它不能对其改变。
3.2.3 URI比较
当比较两个URI是否匹配时，客户端应该以区分大小写的方式一个字符一个字符的比较整个URI。下面是一些例外：
端口没有指定的话等于默认端口；
主机名的比较必须不区分大小写；
URL头部分(前面的http)必须不区分大小写；
空的abs_path等于”/”.
除了在”reserved”和“unsafe”集合中(参见RFC 2396)之外的所有字符等于它的“"%" HEX HEX”码。
例如，以下URI是相等的：
http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html
3.3 日期/时间 格式
3.3.1 完整日期
HTTP应用程序一直以来支持3种日期/时间表示形式：
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中定义)。第二种格式普遍使用，但它是基于过时的RFC 850日期格式，而
且它不是四位数字的年。HTTP/1.1标准的客户端和服务器必须能对这种三种日期格式解析(为了兼容HTTP/1.0)，但是它们放入信息头中
HTTP-date字段的日期只能是RFC 1123格式生成的。
注意：日期的接收方如果可以接受由非HTTP程序发送的日期是受鼓励的，当通过代理/网关向SMTP或NNTP检索或发送消息时，有些时候日期是大写形
式的。
所有HTTP日期/时间必须表示为GMT(格林尼治标准时间)，没有例外。对HTTP而言，GMT精确等于UTC(Coordinated
Universal Time)。在前两种格式中所包含的”GMT”是缩写字母用来表示时区，而当遇到asctime格式的日期时间时必须默认为
GMT。HTTP-date区分大小写并不可以包含除特殊的SP之外多余的LWS。(意思就是在HTTP-date这个字段中存放的日期除了必须的空格
之外不能有多余的空白，如TAB或空格。)
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对日期/时间格式的要求只适用于协议流的用法。客户端和服务器不必一定以这种格式显示给用户或请求日志等等。
3.3.2 Delta Seconds (接收间隔时间)
一些HTTP信息头在接收信息后有一个整数的计时，以秒为单位，十进制显示。(此部分不是很明白)
3.4 字符集
HTTP使用与MIME描述相同的”字符集”定义：
“字符集”在这篇文档中提到了用一个或多个表将八位二进制转换为字符的方法。注意反方向的无条件转换是没有必要的，因为在给出的字符集中不是所有字符都
可用，而且一个字符集可以提供多个八位二进制来表示一个特殊字符。这个定义是为了允许多种字符编码从一个简单的单表映射如US-ASCII到多表的转换
方法，如ISO-2022技术。然而，这种与MIME字符集联系的一起的定义必须完全指定从八位二进制到字符映射的执行。特别是用外部简要信息来决定精
确的映射是不允许的。
