HTTP/1.1（消息格式、连接管理、条件请求、范围请求、缓存、身份验证）

这篇文章主要是对官方文档的翻译和总结，如果有错误的地方，欢迎指正。

概述

1、HTTP（Hypertext Transfer Protocol）超文本传输协议，是一个无状态的应用层请求/响应协议。

2、一些术语：
（1）客户端（client）：HTTP“客户端”是为了发送一个或多个HTTP请求而与服务器建立连接的程序(program)。
（2）服务器（server）：HTTP“服务器”是接受连接以便通过发送HTTP响应来服务HTTP请求的程序。
（3）用户代理（user agent）：指的是发起请求的客户端程序，比如浏览器、网页爬虫、命令行工具、电脑应用程序、手机APP等。
（4）源服务器（origin server）：指可以为给定目标资源(resource)发起权威响应(authoritative responses)的程序。
（5）发送者（sender）：指发送给定消息的任何实现(implementation)。
（6）接收者（recipient）：指接收给定消息的任何实现(implementation)。
（7）中介（intermediary）：位于user agent和origin server之间，如代理(proxy)、网关(gateway)、隧道(tunnel)。
（8）入站（inbound）：用于描述与请求路由相关的方向要求，“入站”表示指向origin server。
（9）出站（outbound）：用于描述与请求路由相关的方向要求，“出站”表示指向user agent。
（10）代理（proxy）：是一种消息转发代理(agent)，由客户端选择，通常通过本地配置规则，接收对某些类型的绝对URI(absolute URI)的请求，并尝试通过HTTP接口的转换(translation)来满足这些请求。
（11）网关（gateway）：又名“反向代理”，是一个intermediary，它充当出站连接的origin server，但转换接收到的请求并将它们转发到另一台或多台服务器。
（12）隧道（tunnel）：充当两个连接之间的盲中继(blind relay)，而不会更改消息。
（13）资源（resource）：HTTP请求的目标，每个资源都由一个URI标识。
（14）权威响应（authoritative response）：是一个由目标URI标识的权威(authority)（或在其指导下）所确定的响应，是在给定 响应消息生成时的目标资源状态 下，该请求的最合适的响应。提供来自非权威来源（比如共享缓存）的响应，对于提高性能和可用性通常很有用，但仅限于来源可信任或这个不可信任的响应能安全使用的情况下。
（15）有效请求URI（effective request URI）：由于request-target(在请求行中，参看“消息格式-开始行”)通常只包含user agent的目标URI的一部分，因此服务器将预定目标重建为“effective request URI”以正确地为请求提供服务。重建规则：比如，如果请求是在TLS-TCP连接中接收到，effective request URI的scheme是https，如果不是则scheme为http；如果request-target是authority-form，则effective request URI的authority部分与request-target相同，如果不是，则如果Host头部字段值非空，则authority部分与Host字段值相同……
（16）有效载荷（payload）：HTTP消息的message body（如果有）用于携带该请求或响应的payload body。除非应用了传输编码(transfer coding)，否则message body与payload body完全相同。（详情参看“消息格式-消息体”。）
（17）表示（representation）：是旨在反映一个给定资源的过去、当前或期望状态的信息，其格式易于通过协议进行通信，由一组representation metadata和representation data的潜在无限流组成。

3、ABNF（Augmented Backus-Naur Form）：
（详情参看RFC7230等官方文档Appendix-ABNF）
一种语法表示方法，比如如果想表示列表的话，语法格式是<n>#<m>element，表示至少n个至多m个元素，元素之间用“,”和OWS(optional whitespace)分隔；比如status-line = HTTP-version SP status-code SP reason-phrase CRLF、status-code = 3DIGIT，表示status-line的格式是“HTTP-version+空格+status-code+空格+reason-phrase+回车换行”（CR (carriage return)、CRLF (CR LF)、LF (line feed)），而里面的status-code的格式是三个数字，还有HTTP-version、SP、reason-phrase、CRLF、DIGIT这些（和status-code一样）在ABNF都有定义；比如absolute-path = 1*( "/" segment )，表示absolute-path的格式是至少一个“/+segment”。
一些ABNF示例：

BWS = OWS
OWS = *( SP / HTAB )
RWS = 1*( SP / HTAB )
qdtext = HTAB / SP / "!" / %x23-5B ; ’#’-’[’
/ %x5D-7E ; ’]’-’˜’
/ obs-text
quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) ; VCHAR: any visible US-ASCII character, HTAB: horizontal tab, SP: space
quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
tchar = "!" / "#" / "$" / "%" / "&" / "’" / "*" / "+" / "-" / "." /
"^" / "_" / "‘" / "|" / "˜" / DIGIT / ALPHA
token = 1*tchar

消息格式

HTTP-message   = start-line
                 *( header-field CRLF )
                 CRLF
                 [ message-body ]

开始行

start-line = request-line / status-line
开始行，对于请求是请求行，对于响应是状态行。
开始行格式：
（1）请求行：

request-line  = method SP request-target SP HTTP-version CRLF
method		  = token
HTTP-version  = HTTP-name "/" DIGIT "." DIGIT
HTTP-name     = %x48.54.54.50 ; "HTTP", case-sensitive

（request-target详情参看“开始行-请求目标”）
例如：GET /user?id=123 HTTP/1.1

（2）状态行：

status-line   = HTTP-version SP status-code SP reason-phrase CRLF
status-code   = 3DIGIT
reason-phrase = *( HTAB / SP / VCHAR / obs-text )

例如：HTTP/1.1 200 OK

请求方法

1、请求方法：（详情参看RFC7231）

• CONNECT
  CONNECT方法请求接收者建立一个到destination origin server(由request-target标识)的隧道(tunnel)，如果成功，则此后将其行为限制为双向盲转发数据包，直到隧道关闭。隧道通常用于创建端到端虚拟连接(通过一个或多个代理)，这个连接之后可以用TLS进行保护。CONNECT仅用于对代理的请求。接收者代理(recipient proxy)可以通过直接连接到request-target来建立隧道，或者如果配置为使用另一个代理，则通过将CONNECT请求转发到下一个入站代理来建立隧道。
• DELETE
  DELETE方法请求origin server移除目标资源与其当前功能(functionality)之间的关联。它表达的是origin server的URI mapping上的删除操作，而不是期望之前关联的信息被删除。如果目标资源具有一个或多个current representation，它们可能会也可能不会被origin server销毁，相关联的存储可能被回收也可能不会，这完全取决于资源的性质和origin server对它的实现。
• GET
  GET方法请求目标资源的current selected representation的传递(transfer)。
• HEAD
  HEAD方法和GET相同，除了服务器不得在响应中发送message body。服务器应该发送相同的头部字段来响应HEAD请求，也就是如果请求是GET时会发送的头部字段，除了payload相关头部字段可以省略。
• OPTIONS
  OPTIONS方法请求可用于目标资源的通信选项(communication options)信息（在origin server或者介于中间的intermediary）。这个方法允许客户端决定与资源相关联的选项(options)、要求(requirements)，或服务器的能力(capabilities)，而无需隐含资源操作(resource action)。如果OPTIONS请求以*作为request-target，则可以用来测试服务器的能力比如是否遵守HTTP/1.1；如果request-target不是*，则请求与目标资源通信时可用的options。
• POST
  POST方法请求目标资源根据资源自身的特定语义处理请求中包含的representation。
• PUT
  PUT方法请求目标资源的状态被创建或替换为请求消息payload中包含的representation所定义的状态。
• TRACE
  TRACE方法请求 请求消息的远程、应用程序级环回(application-level loop-back)。请求的最终接收者应该将收到的消息(除去某些字段)(作为带有Content-Type=message/http的200响应的message body)反射回客户端。最终接收者是origin server或者第一个接收到Max-Forwards=0(在请求中)的服务器。TRACE使得客户端看到在请求链的另一端接收到的内容，并将该数据用于测试或诊断信息。

2、方法属性：
（1）安全方法：如果某个方法的定义语义(defined semantics)本质上是只读的，则认为这个方法是安全的。安全方法的合理使用不会对origin server造成任何伤害、财产损失或异常负担。比如GET、HEAD、OPTIONS、TRACE。
（2）幂等方法：该方法的多个相同的请求和单一请求在服务器上的预期效果(intended effect)一样。比如PUT、DELETE和安全方法。
（3）可缓存方法：该方法的响应允许被存储以备将来重用。比如GET、HEAD、POST。

请求目标

request-target源自(derived from)目标URI。
根据请求方法和请求是否是发给一个代理，request-target有以下四种格式：

request-target = origin-form
               / absolute-form
               / authority-form
               / asterisk-form

（1）origin-form：origin-form = absolute-path [ "?" query ]
当直接向origin server发出请求时，除了CONNECT或服务器范围(server-wide)的OPTIONS请求，客户端必须只发送目标URI的绝对路径(absolute path)和query部分作为request-target（如果目标URI的路径部分为空则用“/”作为origin-form中的path），并且需要Host头部字段。
例如从origin server请求由“http://www.example.org/where?q=now”标识的资源的一个representation，则请求如下：

GET /where?q=now HTTP/1.1
Host: www.example.org

（后面还跟着请求消息的剩余部分。）
（2）absolute-form：absolute-form = absolute-URI
当向代理发出请求时，除了CONNECT或server-wide OPTIONS请求，客户端必须发送absolute-form格式的目标URI作为request-target。（当代理被请求时，它会从有效缓存中为该请求提供服务(如果可能的话)，或者代表客户端向下一个入站代理服务器或直接向request-target指示的origin server发出相同的请求。）
例如：GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
（3）authority-form：authority-form = authority
当发出CONNECT请求以通过一个或多个代理建立隧道时，客户端必须仅发送目标URI的authority部分作为request-target。
例如：CONNECT www.example.com:80 HTTP/1.1
（4）asterisk-form：asterisk-form = "*"
asterisk-form只会用于server-wide OPTIONS请求。当客户端希望为整个服务器请求 OPTIONS时（而不是该服务器的特定命名(named)资源），客户端必须仅发送*作为request-target。
例如：OPTIONS * HTTP/1.1

状态码

（详情参看RFC7231）
status-code的第一个数字定义了响应的类别。客户端可以将无法识别的状态码当作x00，x为第一个数字。

1、1xx（Infomational）
表示请求已经收到，继续处理。这是完成请求的动作和发送最终状态码之前的临时响应，用来沟通连接状态和请求进度。
HTTP/1.0不支持1xx状态码。

• 100（Continue）
  如果请求中包含“Expect: 100-continue”（请求中还没有包含要发送的message body），则100响应表示服务器希望收到请求的payload body。
• 101（Switching Protocols）
  表示服务器将在同一个连接上转换成另一种协议，并且“Upgrade”头部字段会指示出新的协议。

2、2xx（Successful）
表示请求已经被成功收到、理解、接受。

• 200（OK）
  表示请求成功。
• 201（Created）
  表示在服务器创建了一个新资源，并且响应中的Location头部字段提供了所创建资源的标识符(identifier)。
• 202（Accepted）
  表示