1 Introduction
https://www.rfc-editor.org/in…
1.1 Purpose
超文本传输协定（HTTP）是一种为分布式，单干式，多媒体信息系统服务的，面向应用层的协定
容许音讯以相似 MIME 的格局传送
性能缺失：分层代理 缓存 长久化连贯 虚拟主机
建设在 URI（URL URN）之上
申请办法
申请头
Multipurpose Internet Mail Extensions (MIME)
是一种用户代理和网关 / 代理到其余互联网服务器的通用协定。这些网络程序可能由 SMTP [16], NNTP [13], FTP [18], Gopher [2], and WAIS [10] 协定形成 1.3 Terminology 术语
connection
A transport layer virtual circuit established between two programs for the purpose of communication.
message
HTTP 通信根本单元，应用字节序列通过 connection 传输
request
An HTTP request message
response
An HTTP response message
resource
用 URI 标识网络数据对象和服务，资源能够有多种示意模式 (例如多种语言、数据格式、大小和分辨率)
entity
申请头（metainformation 元信息）+ 申请体，section 7
representation 示意
特定 response status 有多种示意
content negotiation 内容协商
解决申请抉择适当的体现机制。所有响应中实体的示意都是能够协商的（包含谬误响应）section 12
variant 变体
给定任何时候，一个 resource 可能对应一个或多个 representation，每种 representation 都称为 varriant
varriant 不代表 resource 受制于 content negotiation
client
为发送申请而建设连贯的程序
user agent 用户代理
发动申请的客户端
server
接管连贯返回响应的应用程序。每个程序都能够是 origin server, proxy, gateway, or tunnel, 基于他们每个申请的行为。origin server 源服务器
The server on which a given resource resides or is to be created.
特定资源创立或所在的服务器
proxy 代理器
两头服务器，MUST 同时实现 client sever。为申请提供服务或转发（可能会转换）到其余服务器。transparent proxy：通明服务器，不批改申请和响应，用户验证和辨认除外
non-transparent proxy：非通明服务器，批改申请和响应。为 user agent 增加一个服务，比方 group annotation services, media type transformation, protocol reduction, or anonymity filtering。除非明确申明了通明、非通明，否则 HTTP proxy requirements 同时反对这两种模式
gateway 网关
网关对申请方来说就像源服务器一样
tunnel
申请的两端敞开，隧道也不复存在
first-head
响应间接来自 origin server，没通过 proxy。upstream/downstream 上游 上游
Upstream and downstream 形容信息流，所有信息都是从上游流向上游。此处的信息是指申请 + 响应码？inbound/outbound
inbound：向 origin server 挪动
outbound：向 user agent 挪动 1.4 Overall Operation
HTTP protocol 是 request/response 协定.
客户端通过一条与服务端的连贯发送申请，服务端解决申请后返回响应
申请格局：request method, URI, protocol version
MIME-like message containing reques modifiers, client information, possible body content
响应格局：status line：message's protocol version, success or error code
MIME-like message containing server information, entity metainformation, possible entity-body content.
HTTP 与 MIME 的关系位于附录 19.4.
---------------------------- demo 1 ----------------------------
connection (v) user agent (UA) origin server (O).
request chain ------------------------>
UA -------------------v------------------- O
<----------------------- response chain
---------------------------- demo 2 ----------------------------
当 request/response chain 中存在 intermediaries 时，状况会变简单。有三种常见 intermediaries：proxy, gateway, and tunnel.
proxy：转发代理，承受相对模式的 uri 申请，重写 message，从新格式化 request 而后转发
gateway：必要时转换申请的协定。tunnel：不改写音讯，通过 intermediary（例如 firewall），或者 intermediary 无奈了解音讯时能够应用 tunnel
request chain -------------------------------------->
UA -----v----- A -----v----- B -----v----- C -----v----- O
<------------------------------------- response chain
上图显示了 user agent/origin server 之间的三个中介体 (A、B 和 C)，须要四个独立的连贯。这个区别很重要，某些 HTTP 通信选项别离实用于邻近节点，非隧道的邻近节点，调用链的终端，任意节点。---------------------------- demo 3 | 缓存 ----------------------------
request chain ---------->
UA -----v----- A -----v----- B - - - - - - C - - - - - - O
<--------- response chain
省略对于缓存的一千字 ......
---------------------------- ---------------------------- ----------------------------
HTTP 通信通常应用 TCP/IP connections，默认端口 TCP 80。能够应用任意 Internet 或其余协定。HTTP 假如传输是牢靠的，任意牢靠传输的协定都能够应用; HTTP1.1 申请、响应的构造到 transport data units 的映射不在本标准范畴内。HTTP1.1 连贯可复用，只管可能因各种起因敞开（see section 8.1）2 Notational Conventions and Generic Grammar 符号习惯和个别语法
2.1 Augmented BNF 增强型 Backus-Naur Form
本文规定的所有机制都能够用两种形式形容：散文体（prose）和相似于 RFC 822 的裁减 Backus-Naur Form（BNF）name = definition
name 代表规定的名称（不能包含 '<' '>' 字符），应用 = 将名称和定义离开，空白是定义的分隔符。根本规定用大写，例如 SP, LWS, HT, CRLF, DIGIT, ALPHA
'<' '>' 能够蕴含在定义中，用于标识规定名。literal（字面量）文本需加 '', 不辨别大小写
rule1 | rule2 rule1 或 rule2
(rule1 rule2) () 包起来的元素视为繁多元素
*rule 反复
* 示意 0~inf
<n>*<m> 示意 n 到 m 次
[rule] [foo bar] == *1(foo bar)
N rule <n>(element) == <n>*<n>(element)
#rule 相似于 *，将元素用 (",") 以及 (LWS) 隔开
1#element == (*LWS element *( *LWS "," *LWS element))
容许呈现 (element), , (element)
; 正文
implied *LWS 元素之间须要一个分隔符 2.2 Basic Rules
US-ASCII（美国信息替换规范码）编码字符集是由 ANSI X3.4-1986 定义
OCTET = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)>
UPALPHA = <any US-ASCII uppercase letter "A".."Z">
LOALPHA = <any US-ASCII lowercase letter "a".."z">
ALPHA = UPALPHA | LOALPHA
DIGIT = <any US-ASCII digit "0".."9">
CTL = <any US-ASCII control character
(octets 0 - 31) and DEL (127)>
CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)>
SP = <US-ASCII SP, space (32)>
HT = <US-ASCII HT, horizontal-tab (9)>
<"> = <US-ASCII double-quote mark (34)>
CRLF = CR LF
HTTP/1.1 将 CR LF 定义为行尾标记
LWS = [CRLF] 1*（SP | HT）与 SP 具备雷同的语义
TEXT = <any OCTET except CTLs, but including LWS>
HEX = "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
token = 1*<any CHAR except CTLs or separators>
separators = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" |
<"> |"/"|"["|"]"|"?"|"="|"{"|"}" | SP | HT
--------------- 正文相干 ---------------
comment = "(" *( ctext | quoted-pair | comment) ")"
ctext = <any TEXT excluding "(" and ")">
quoted-string = (<"> *(qdtext | quoted-pair) <"> )
qdtext = <any TEXT except <">>
quoted-pair = "\" CHAR3 Protocol Parameters 协定参数
3.1 HTTP Version
格局 <major>.<minor>
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
HTTP/1.0 HTTP/1.1
网关 / 代理若收到高版本的音讯，MUST 升高申请的版本、报错、切换到 tunnel
不同版本之间，申请头会有肯定兼容性问题 3.2 Uniform Resource Identifiers
URIs 别名：WWW addresses, Universal Document Identifiers, Universal Resource Identifiers, URL, URN
对 HTTP 来说 URL 仅仅是格式化的字符串 3.2.2 http URL
http_URL = "http:" "//" host [":" port] [abs_path [ "?" query]]
port default 80
防止应用 IP 代替 host3.2.3 URI Comparison
一个一个字节比拟，并辨别大小写
非凡状况
- 端口有默认值，（见 RFC 2396）里的默认端口
- host 不分大小写
- scheme 不分大小写
- abs_path 为空等同与 "/"
除了 "保留（reserved）" 和 "不平安（unsafe）" 字符集里的字符（参见 RFC 2396）其余字符等效于他们的 "%HEXHEX" 编码
http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html3.3 Date/Time Formats
3.4 Character Sets
charset = token
charset 最好合乎 IETF Policy on Character Sets and Languages(https://www.rfc-editor.org/rfc/rfc2277) 的要求
----------------- demo -----------------
Content-Type: text/plain; charset=UTF-83.4.1 被疏忽的字符集
有些 HTTP 1.0 不能解决在 Content-Type 头域里明确指定的字符集参数（entity body，译注：这里翻译成“实体主体”因为 Content-Type 头是实体头，音讯头能够分为实体头，罕用头，申请头，响应头，在译文中屡次用到“头”和“头域”，如音讯头，音讯头域，其实是同一个意思，HTTP1.1 协定有时候概念并不是齐全对立的）3.5 内容编码（Content Codings）
content-coding = token
gzip compress Welch deflate identity(default)3.6 传输编码（Transfer Codings）
3.6.1 块传输编码（Chunked Transfer Coding）
3.7 媒体类型（Media Type）
HTTP 在头字段 Content-Type, Accept 中应用 Internet Media Types
media-type = type "/" subtype *(";" parameter)
type = token
subtype = token
Content-Type: text/html; charset=UTF-8
Media-type 必须在 IANA 注册过
未注册的媒体类型不激励应用 3.7.1 规范化和文本缺省（Canonicalization and Text Defaults）
HTTP 应用程序 MUST 能接管 CRLF，CR 和 LF 作为文本媒体的换行符
HTTP 容许利用字符集里等价于 CR 和 LF 的字节序列来示意换行符
实体主体局部能够应用 CR 和 LF，其余不行
默认 ISO-8859-13.7.2 多局部类型（Multipart type）
4 HTTP Message
4.1 Message Types 音讯类型
HTTP-message = Request|Response ;HTTP/1.1
格局：generic-message = start-line
*（message-header CRLF）CRLF
[message-body]
start-line = Request-Line | Status-Line
为了健壮性，服务器应该疏忽任意申请行（Request-Line）后面的空行
某些由问题的 HTTP/1.0 实现会在申请前面加一些 CRLF
一个 HTTP/1.1 客户端 MUST NOT 在申请前和申请后加 CRLF4.2 Message Headers
header 分类：general-header (section 4.5)
request-header (section 5.3)
response-header (section 6.2)
entity-header (section 7.1)
格局：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>
LWS 呈现在 field-content 中 MAY 会被 SP 代替
头字段程序的 "good practice"
1. general-header fields
2. request-header or response-header fields
3. entity-header
当一个 header 有多个值，网关代理 MUST 按原来的值程序转发。cache-control: no-cache, no-store, no-transform4.3 Message body 音讯主体
message-body 用于承载申请和响应的 entity-body
message-body = entity-body | <entity-body encoded as per Transfer-Encoding>
Transfer-Encoding MUST 用于指定 transfer-codings
Transfer-Encoding 是音讯的属性，不是实体的属性
音讯主体是否呈现在音讯中的判断条件
1. 由 header Content-Length 或 Transfer-Encoding 来暗示。2. request Method
3. response Method or 响应状态码（1XX 204 304）4.4 Message Length 音讯长度
message 的 transfer-length 是 message-body 的长度;
transfer-length 由以下条件决定 (按优先级排序):
1. response message MUST NOT 包含 message-body
such as 1xx, 204, and 304
申请办法为 HEAD 的响应
2. Transfer-Encoding 存在，值不为 identity。transfer-length 定义在 chunked 中（section 3.6）3. Content-Length 存在，值为 entity-length 用 OCTETs 示意的十进制。若 entity-length 与 transfer-length 不相等，阐明应用了 Transfer-Encoding。同时应用 Transfer-Encoding 和 Content-Length，Content-Length 会被疏忽
4. multipart/byteranges（自定义媒体），客户端需与服务端协商好传输长度。能够应用 header:Range
HTTP1.1 存在 Transfer-Encoding
蕴含音讯体，然而 Content-Length 不存在, 服务器 SHOULD 响应 400 (bad request) 或者 411 (length required)
MUST 接管 "chunked" 传输编码（section 3.6）同时存在 Transfer-Encoding（值不为 identity）和 Content-Length，Content-Length MUST 被疏忽 4.5 General Header Fields 罕用头
有些 header 即实用于 申请，也实用于响应，但不实用与 实体。
general-header = Cache-Control ; Section 14.9
| Connection ; Section 14.10
| Date ; Section 14.18
| Pragma ; Section 14.32
| Trailer ; Section 14.40
| Transfer-Encoding ; Section 14.41
| Upgrade ; Section 14.42
| Via ; Section 14.45
| Warning ; Section 14.465 Request 申请
Request = Request-Line ; Section 5.1
*(( general-header ; Section 4.5
| request-header ; Section 5.3
| entity-header ) CRLF) ; Section 7.1
CRLF
[message-body] ; Section 4.35.1 Request-Line
Request-Line = Method SP Request-URI SP HTTP-Version CRLF5.1.1 Method
Method = "OPTIONS" ; Section 9.2
| "GET" ; Section 9.3
| "HEAD" ; Section 9.4
| "POST" ; Section 9.5
| "PUT" ; Section 9.6
| "DELETE" ; Section 9.7
| "TRACE" ; Section 9.8
| "CONNECT" ; Section 9.9
| extension-method
extension-method = token
405 (Method Not Allowed)
501 (Not Implemented)
GET and HEAD MUST be supported5.1.2 Request-URI
Request-URI ="*" | absoluteURI | abs_path | authotity
OPTIONS * HTTP/1.1
absoluteURI
GET http://www.w3.org/pub/www/TheProject.html HTTP/1.1
abs_path
GET /pub/WWW/TheProject.html HTTP/1.1
Host：www.w3.org5.2 申请资源 The Resource Identified by a Request
Internet request 资源标识通过 Request-URI 和 Host header field.
1. Request-URI 是 absoluteURI，MUST 疏忽 Host
2. Request-URI 非 absoluteURI，Host 决定 host
3. 不满足 1, 2。response MUST 400(Bad Request) 5.3 申请头 Request Header Fields
申请的附加音讯或客户端的附加音讯
request-header = Accept ; Section 14.1
| Accept-Charset ; Section 14.2
| Accept-Encoding ; Section 14.3
| Accept-Language ; Section 14.4
| Authorization ; Section 14.8
| Expect ; Section 14.20
| From ; Section 14.22
| Host ; Section 14.23
| If-Match ; Section 14.24
| If-Modified-Since ; Section 14.25
| If-None-Match ; Section 14.26
| If-Range ; Section 14.27
| If-Unmodified-Since ; Section 14.28
| Max-Forwards ; Section 14.31
| Proxy-Authorization ; Section 14.34
| Range ; Section 14.35
| Referer ; Section 14.36
| TE ; Section 14.39
| User-Agent ; Section 14.436 Response 响应
Response = Status-Line ; Section 6.1
*(( general-header ; Section 4.5
| response-header ; Section 6.2
| entity-header ) CRLF) ; Section 7.1
CRLF
[message-body] ; Section 7.2
6.1 Status-Line
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF6.1.1 Status Code and Reason Phrase
1xx: Informational 音讯 - Request received, continuing process 接管到音讯，持续过程
2xx: Success 胜利 - The action was successfully received, understood, and accepted
3xx: Redirection 重定向 - Further action must be taken in order to complete the request
4xx: Client Error 客户端谬误 - The request contains bad syntax or cannot be fulfilled
5xx: Server Error 服务器谬误 - The server failed to fulfill an apparently valid requestStatus-Code =
|"200" ; 10.2.1 节: OK
| extension-code
extension-code =3DIGIT
Reason-Phrase = *<TEXT,excluding CR,LF>
具体 code 见原文 https://www.rfc-editor.org/rfc/rfc2616.html#section-6.1.16.2 Response Header Fields
响应的附加音讯或服务端的附加音讯
response-header = Accept-Ranges ; Section 14.5
| Age ; Section 14.6
| ETag ; Section 14.19
| Location ; Section 14.30
| Proxy-Authenticate ; Section 14.33
| Retry-After ; Section 14.37
| Server ; Section 14.38
| Vary ; Section 14.44
| WWW-Authenticate ; Section 14.477 Entity 实体
Request and Response messages MAY 传输实体，如果不受 request method 或 response status code 限度.
entity = entity-header fields + entity-body7.1 Entity Header Fields
entity-header = Allow ; Section 14.7
| Content-Encoding ; Section 14.11
| Content-Language ; Section 14.12
| Content-Length ; Section 14.13
| Content-Location ; Section 14.14
| Content-MD5 ; Section 14.15
| Content-Range ; Section 14.16
| Content-Type ; Section 14.17
| Expires ; Section 14.21
| Last-Modified ; Section 14.29
| extension-header
extension-header = message-header
接管方能够疏忽未辨认 header7.2 Entity Body
entity-body = *OCTET
entity-body 由 message-body 依据 Transfer-Encoding decoding 后失去 7.2.1 Type
音讯体的数据类型由 Content-Encoding 和 Content-Type 指定
entity-body := Content-Encoding(Content-Type( data) )
Content-Type 指定数据的 media type
Content-Encoding 指定 content codings
MAY 媒体类型首先看 Content-Type，其次从数据内容或 URI 来推断，SHOULD 最初指定为 application/octec-stream7.2.2 Entity Length
transfer-coding 之前的长度 8 连贯 Connections
8.1 长久化连贯 Persistent Connections
8.1.1 目标 Purpose
长久化连贯有数个劣势：1. 缩小 TCP 开启敞开次数, 节俭路由器和主机 (hosts：clients, servers, proxies, gateways, tunnels, or caches) 的 CPU time, 节俭主机上 TCP protocol control blocks 占用的内存。2. 能够在连贯上开启 Pipelining。容许客户端收回多个申请而无需期待每个响应。3. 缩小报文数量，并有足够的工夫确定网络拥塞（congestion）状态，缩小网络拥塞
4. 后续连贯，节俭了三次握手
5. 报错后无需敞开 TCP 连贯，能够乐观的尝试新个性。SHOULD 实现长久化连贯 8.1.2 整体操作 Overall Operation
HTTP 1.1 默认长久化连贯
Persistent connections 能够应用 header Connection 来敞开 close of a TCP connection
一旦发送敞开信号, 客户端 MUST NOT 堆这条连贯发送任何申请 8.1.2.1 协商（Negotiation）
HTTP/1.1 client 和 server 默认放弃连贯，直到申请头 Connection 携带 connection-token close
HTTP/1.0 向后兼容见 section 19.6.2
长久化连贯所有音讯 MUST 携带 message length, 详情见 section 4.48.1.2.2 流水线 Pipelining
MUST：流水线必须在长久化连贯上开启
SHOULD：应用流水线时，须要应用幂等办法（see section 9.1.2）。8.1.3 Proxy Servers
MUST：代理不能为 HTTP/1.0 的客户端建设长久化连贯 8.1.4 最佳实际 Practical Considerations
1. 须要为非沉闷中的连贯设置一个超时工夫（time-out）。2. SHOULD：客户端服务器超时敞开时，应该按标准敞开连贯。客户端和服务器须要时刻查看对方是否敞开了连贯。3. MAY：客户端，服务器，代理能够在任何时候敞开连贯。当服务器敞开连贯时，客户端发动申请，倡议应用重试 + 幂等办法保障这次申请的胜利
4. 服务器的连接数倡议放弃在 2N，N = 同时在线用户数
以上准则都是为了升高响应工夫和防止阻塞 8.2 音讯传送要求 Message Transmission Requirements
8.2.1 长久化连贯和流量管制 Persistent Connections and Flow Control
HTTP/1.1 服务器该当放弃继续连贯并应用 TCP 流量管制机制来解决长期过载。客户端重试会导致拥塞好转 8.2.2 监控连贯的谬误状态
SHOULD：HTTP/1.1 (or later) client 发送 message-body 时应该监控 network connection 的状态。发现错误立刻进行音讯主体的发送。应用 chuck 传输，能够用长度为 0 的块和 empty trailer 来完结音讯。header 上有 Content-Length MUST 马上敞开连贯 8.2.4 服务端过早敞开连贯时客户端的行为
// TODO9 办法定义
办法有很多, 此处只关注 GET POST
9.1 平安和等幂（Idempotent）办法
9.1.1 平安办法
GET 获取资源时平安，action（执行动作）时不保障平安
POST 执行动作时平安
GET 查问平安
POST 增删改查都平安 9.1.2 等幂办法
GET POST 都是幂等办法
除了 error or expiration 问题，雷同参数返回雷同后果 9.3 GET
当申请头中蕴含 If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range，GET 办法语义将改为 "conditional GET"
满足条件时响应中返回实体，否则应用缓存。GET 申请的响应是可缓存的（cacheable），详情见 section 13.
应用表单时的平安问题，见 section 15.1.39.5 POST
性能如下：- 已存在的资源的正文；- 公布音讯给一个布告板，新闻组，邮件列表，或者类似的文章组。- 提供一个数据块，如提交一个表单给一个数据处理过程。- 通过追加操作来扩大数据库。响应可缓存，除非响应头中蕴含 Cache-Control 或 Expires。10 状态码
RFC 2616：超文本传输协定 — HTTP/1.1#section-10
11 拜访认证
12 内容协商 Content Negotiation
HTTP 提供了几种内容协商的机制 -- 多种示意形式可用时，为响应抉择最佳示意形式。内容协商不是格局协商，因为 representations 可能是同样的 media type，然而利用了 media type 的不同性质，例如语言
内容协商在 HTTP 中由两种类型：服务器驱动协商和代理驱动协商。也能够联结应用 12.1 服务器驱动协商（Server-driven Negotiation）
通过服务器算法选择响应最好的表现形式。12.2 代理驱动协商（Agent-driven Negotiation）
12.3 通明协商（Transparent Negotiation）
13. 缓存 Cache
14. 申请头定义
14.7 Allow
Allow = "Allow" ":" #Method
Allow: GET, HEAD, PUT14.10 Connection
Connection = "Connection" ":" 1#(connection-token)
connection-token = token
Connection: close14.13 Content-Length
Content-Length = "Content-Length" ":" 1*DIGIT
Content-Length: 3495
限度条件见 section 4.414.17 Content-Type
Content-Type = "Content-Type" ":" media-type
Content-Type: text/html; charset=ISO-8859-4……