共计 13940 个字符，预计需要花费 35 分钟才能阅读完成。
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 = "\" CHAR |
3 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 代替 host |
3.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.html |
3.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-8 |
3.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-1 |
3.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 在申请前和申请后加 CRLF |
4.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-transform |
4.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.46 |
5 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.3 |
5.1 Request-Line
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
5.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 supported |
5.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.org |
5.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.43 |
6 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 CRLF
6.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 request |
| Status-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.1 |
6.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.47 |
7 Entity 实体
| Request and Response messages MAY 传输实体，如果不受 request method 或 response status code 限度. | |
| entity = entity-header fields + entity-body |
7.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 | |
| 接管方能够疏忽未辨认 header |
7.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-stream |
7.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.4 |
8.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 服务端过早敞开连贯时客户端的行为
// TODO
9 办法定义
办法有很多, 此处只关注 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.3 |
9.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, PUT |
14.10 Connection
| Connection = "Connection" ":" 1#(connection-token) | |
| connection-token = token | |
| Connection: close |
14.13 Content-Length
| Content-Length = "Content-Length" ":" 1*DIGIT | |
| Content-Length: 3495 | |
| 限度条件见 section 4.4 |
14.17 Content-Type
| Content-Type = "Content-Type" ":" media-type | |
| Content-Type: text/html; charset=ISO-8859-4 |
……
正文完
