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 versionMIME-like message containing reques modifiers, client information, possible body content响应格局：status line：message's protocol version, success or error codeMIME-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 = definitionname 代表规定的名称（不能包含 '<' '>' 字符），应用 = 将名称和定义离开，空白是定义的分隔符。根本规定用大写，例如 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 | LOALPHADIGIT = <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" | DIGITtoken = 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*DIGITHTTP/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 = tokencharset 最好合乎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 = tokengzip 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 Typesmedia-type = type "/" subtype *( ";" parameter )type = tokensubtype = tokenContent-Type: text/html; charset=UTF-8Media-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 = tokenfield-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-bodymessage-body = entity-body | <entity-body encoded as per Transfer-Encoding>Transfer-Encoding MUST 用于指定 transfer-codingsTransfer-Encoding 是音讯的属性，不是实体的属性音讯主体是否呈现在音讯中的判断条件1. 由 header Content-Length 或 Transfer-Encoding 来暗示。2. request Method3. 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:RangeHTTP1.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 | authotityOPTIONS * HTTP/1.1absoluteURIGET http://www.w3.org/pub/www/TheProject.html HTTP/1.1abs_pathGET /pub/WWW/TheProject.html HTTP/1.1Host：www.w3.org5.2 申请资源 The Resource Identified by a Request
Internet request 资源标识通过 Request-URI 和 Host header field. 1. Request-URI 是 absoluteURI， MUST 疏忽 Host2. Request-URI 非 absoluteURI， Host 决定 host3. 不满足 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.26.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 accepted3xx: Redirection 重定向 - Further action must be taken in order to complete the request4xx: Client Error 客户端谬误 - The request contains bad syntax or cannot be fulfilled5xx: Server Error 服务器谬误 - The server failed to fulfill an apparently valid requestStatus-Code = |"200" ; 10.2.1节: OK | extension-codeextension-code =3DIGITReason-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 = *OCTETentity-body 由 message-body 依据 Transfer-Encoding decoding 后失去7.2.1 Type
音讯体的数据类型由 Content-Encoding 和 Content-Type 指定
entity-body := Content-Encoding( Content-Type( data ) )Content-Type 指定数据的 media typeContent-Encoding 指定 content codingsMAY 媒体类型首先看 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 closeHTTP/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" ":" #MethodAllow: GET, HEAD, PUT14.10 Connection
Connection = "Connection" ":" 1#(connection-token)connection-token = tokenConnection: close14.13 Content-Length
Content-Length = "Content-Length" ":" 1*DIGITContent-Length: 3495限度条件见 section 4.414.17 Content-Type
Content-Type = "Content-Type" ":" media-typeContent-Type: text/html; charset=ISO-8859-4......