![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 1393
- Timestamp:
- 09/08/11 00:46:19 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
-
p1-messaging.html (modified) (42 diffs)
-
p1-messaging.xml (modified) (10 diffs)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1392 r1393 570 570 </li> 571 571 <li>3. <a href="#http.message">Message Format</a><ul> 572 <li>3.1 <a href="#message.robustness">Message Parsing Robustness</a></li> 573 <li>3.2 <a href="#header.fields">Header Fields</a></li> 572 <li>3.1 <a href="#message.robustness">Message Parsing and Robustness</a></li> 573 <li>3.2 <a href="#header.fields">Header Fields</a><ul> 574 <li>3.2.1 <a href="#field.parsing">Field Parsing</a></li> 575 <li>3.2.2 <a href="#field.length">Field Length</a></li> 576 <li>3.2.3 <a href="#field.rules">Common Field ABNF Rules</a></li> 577 </ul> 578 </li> 574 579 <li>3.3 <a href="#message.body">Message Body</a></li> 575 580 <li>3.4 <a href="#incomplete.messages">Incomplete Messages</a></li> … … 845 850 <a href="#rule.whitespace" class="smpl">obs-fold</a> = <a href="#core.rules" class="smpl">CRLF</a> 846 851 ; see <a href="#header.fields" title="Header Fields">Section 3.2</a> 847 </pre><div id="rule.token.separators"> 848 <p id="rfc.section.1.2.2.p.7"> Many HTTP/1.1 header field values consist of words (token or quoted-string) separated by whitespace or special characters. 849 These special characters <em class="bcp14">MUST</em> be in a quoted string to be used within a parameter value (as defined in <a href="#transfer.codings" title="Transfer Codings">Section 6.2</a>). 850 </p> 851 </div> 852 <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span> <a href="#rule.token.separators" class="smpl">word</a> = <a href="#rule.token.separators" class="smpl">token</a> / <a href="#rule.quoted-string" class="smpl">quoted-string</a> 853 854 <a href="#rule.token.separators" class="smpl">token</a> = 1*<a href="#rule.token.separators" class="smpl">tchar</a> 855 856 <a href="#rule.token.separators" class="smpl">tchar</a> = "!" / "#" / "$" / "%" / "&" / "'" / "*" 857 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" 858 / <a href="#core.rules" class="smpl">DIGIT</a> / <a href="#core.rules" class="smpl">ALPHA</a> 859 ; any <a href="#core.rules" class="smpl">VCHAR</a>, except <a href="#rule.token.separators" class="smpl">special</a> 860 861 <a href="#rule.token.separators" class="smpl">special</a> = "(" / ")" / "<" / ">" / "@" / "," 862 / ";" / ":" / "\" / DQUOTE / "/" / "[" 863 / "]" / "?" / "=" / "{" / "}" 864 </pre><div id="rule.quoted-string"> 865 <p id="rfc.section.1.2.2.p.9"> A string of text is parsed as a single word if it is quoted using double-quote marks.</p> 866 </div> 867 <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span> <a href="#rule.quoted-string" class="smpl">quoted-string</a> = <a href="#core.rules" class="smpl">DQUOTE</a> *( <a href="#rule.quoted-string" class="smpl">qdtext</a> / <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> ) <a href="#core.rules" class="smpl">DQUOTE</a> 868 <a href="#rule.quoted-string" class="smpl">qdtext</a> = <a href="#rule.whitespace" class="smpl">OWS</a> / %x21 / %x23-5B / %x5D-7E / <a href="#rule.quoted-string" class="smpl">obs-text</a> 869 ; <a href="#rule.whitespace" class="smpl">OWS</a> / <<a href="#core.rules" class="smpl">VCHAR</a> except <a href="#core.rules" class="smpl">DQUOTE</a> and "\"> / <a href="#rule.quoted-string" class="smpl">obs-text</a> 870 <a href="#rule.quoted-string" class="smpl">obs-text</a> = %x80-FF 871 </pre><div id="rule.quoted-pair"> 872 <p id="rfc.section.1.2.2.p.11"> The backslash octet ("\") can be used as a single-octet quoting mechanism within quoted-string constructs:</p> 873 </div> 874 <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.23"></span> <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> = "\" ( <a href="#core.rules" class="smpl">WSP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> ) 875 </pre><p id="rfc.section.1.2.2.p.13">Recipients that process the value of the quoted-string <em class="bcp14">MUST</em> handle a quoted-pair as if it were replaced by the octet following the backslash. 876 </p> 877 <p id="rfc.section.1.2.2.p.14">Senders <em class="bcp14">SHOULD NOT</em> escape octets that do not require escaping (i.e., other than DQUOTE and the backslash octet). 878 </p> 879 <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="architecture" href="#architecture">HTTP-related architecture</a></h1> 852 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="architecture" href="#architecture">HTTP-related architecture</a></h1> 880 853 <p id="rfc.section.2.p.1">HTTP was created for the World Wide Web architecture and has evolved over time to support the scalability needs of a worldwide 881 854 hypertext system. Much of that architecture is reflected in the terminology and syntax productions used to define HTTP. … … 903 876 the origin server (O). 904 877 </p> 905 <div id="rfc.figure.u. 12"></div><pre class="drawing"> request >878 <div id="rfc.figure.u.9"></div><pre class="drawing"> request > 906 879 UA ======================================= O 907 880 < response … … 918 891 </p> 919 892 <p id="rfc.section.2.1.p.7">The following example illustrates a typical message exchange for a GET request on the URI "http://www.example.com/hello.txt":</p> 920 <div id="rfc.figure.u.1 3"></div>893 <div id="rfc.figure.u.10"></div> 921 894 <p>client request:</p><pre class="text2">GET /hello.txt HTTP/1.1 922 895 User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 … … 924 897 Accept: */* 925 898 926 </pre><div id="rfc.figure.u.1 4"></div>899 </pre><div id="rfc.figure.u.11"></div> 927 900 <p>server response:</p><pre class="text">HTTP/1.1 200 OK 928 901 Date: Mon, 27 Jul 2009 12:28:53 GMT … … 967 940 switching behavior based on the nature of each request. 968 941 </p> 969 <div id="rfc.figure.u.1 5"></div><pre class="drawing"> > > > >942 <div id="rfc.figure.u.12"></div><pre class="drawing"> > > > > 970 943 <b>UA</b> =========== <b>A</b> =========== <b>B</b> =========== <b>C</b> =========== <b>O</b> 971 944 < < < < … … 994 967 a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics. See <a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 8.2.4</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> for status and warning codes related to transformations. 995 968 </p> 996 <p id="rfc.section.2.4.p.7"><span id="rfc.iref.g. 24"></span><span id="rfc.iref.r.4"></span> <span id="rfc.iref.a.1"></span> A "<dfn>gateway</dfn>" (a.k.a., "<dfn>reverse proxy</dfn>") is a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying969 <p id="rfc.section.2.4.p.7"><span id="rfc.iref.g.16"></span><span id="rfc.iref.r.4"></span> <span id="rfc.iref.a.1"></span> A "<dfn>gateway</dfn>" (a.k.a., "<dfn>reverse proxy</dfn>") is a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying 997 970 server's protocol. Gateways are often used to encapsulate legacy or untrusted information services, to improve server performance 998 971 through "<dfn>accelerator</dfn>" caching, and to enable partitioning or load-balancing of HTTP services across multiple machines. … … 1026 999 from O (via C) for a request which has not been cached by UA or A. 1027 1000 </p> 1028 <div id="rfc.figure.u.1 6"></div><pre class="drawing"> > >1001 <div id="rfc.figure.u.13"></div><pre class="drawing"> > > 1029 1002 UA =========== A =========== B - - - - - - C - - - - - - O 1030 1003 < < … … 1044 1017 </p> 1045 1018 <p id="rfc.section.2.6.p.2">The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message. HTTP-Version is case-sensitive.</p> 1046 <div id="rfc.figure.u.1 7"></div><pre class="inline"><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span> <a href="#http.version" class="smpl">HTTP-Version</a> = <a href="#http.version" class="smpl">HTTP-Prot-Name</a> "/" <a href="#core.rules" class="smpl">DIGIT</a> "." <a href="#core.rules" class="smpl">DIGIT</a>1019 <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span> <a href="#http.version" class="smpl">HTTP-Version</a> = <a href="#http.version" class="smpl">HTTP-Prot-Name</a> "/" <a href="#core.rules" class="smpl">DIGIT</a> "." <a href="#core.rules" class="smpl">DIGIT</a> 1047 1020 <a href="#http.version" class="smpl">HTTP-Prot-Name</a> = %x48.54.54.50 ; "HTTP", case-sensitive 1048 1021 </pre><p id="rfc.section.2.6.p.4">The HTTP version number consists of two decimal digits separated by a "." (period or decimal point). The first digit ("major … … 1103 1076 "path-absolute", "query", and "authority" from the URI generic syntax <a href="#RFC3986" id="rfc.xref.RFC3986.4"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>. In addition, we define a partial-URI rule for protocol elements that allow a relative URI but not a fragment. 1104 1077 </p> 1105 <div id="rfc.figure.u.1 8"></div><pre class="inline"><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span><span id="rfc.iref.g.32"></span><span id="rfc.iref.g.33"></span> <a href="#uri" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.5"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.1">Section 4.1</a>>1078 <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span> <a href="#uri" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.5"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.1">Section 4.1</a>> 1106 1079 <a href="#uri" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.6"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.3">Section 4.3</a>> 1107 1080 <a href="#uri" class="smpl">relative-part</a> = <relative-part, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.7"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>> … … 1125 1098 namespace governed by a potential HTTP origin server listening for TCP connections on a given port. 1126 1099 </p> 1127 <div id="rfc.figure.u.1 9"></div><pre class="inline"><span id="rfc.iref.g.34"></span> <a href="#http.uri" class="smpl">http-URI</a> = "http:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ]1100 <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.26"></span> <a href="#http.uri" class="smpl">http-URI</a> = "http:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ] 1128 1101 </pre><p id="rfc.section.2.7.1.p.3">The HTTP origin server is identified by the generic syntax's <a href="#uri" class="smpl">authority</a> component, which includes a host identifier and optional TCP port (<a href="#RFC3986" id="rfc.xref.RFC3986.14"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.2">Section 3.2.2</a>). The remainder of the URI, consisting of both the hierarchical path component and optional query component, serves as an 1129 1102 identifier for a potential resource within that origin server's name space. … … 1164 1137 TCP port of 443 is assumed if the port subcomponent is empty or not given, and the TCP connection <em class="bcp14">MUST</em> be secured for privacy through the use of strong encryption prior to sending the first HTTP request. 1165 1138 </p> 1166 <div id="rfc.figure.u. 20"></div><pre class="inline"><span id="rfc.iref.g.35"></span> <a href="#https.uri" class="smpl">https-URI</a> = "https:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ]1139 <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.27"></span> <a href="#https.uri" class="smpl">https-URI</a> = "https:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ] 1167 1140 </pre><p id="rfc.section.2.7.2.p.4">Unlike the "http" scheme, responses to "https" identified requests are never "public" and thus <em class="bcp14">MUST NOT</em> be reused for shared caching. They can, however, be reused in a private cache if the message is cacheable by default in HTTP 1168 1141 or specifically indicated as such by the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). … … 1185 1158 </p> 1186 1159 <p id="rfc.section.2.7.3.p.3">For example, the following three URIs are equivalent:</p> 1187 <div id="rfc.figure.u. 21"></div><pre class="text"> http://example.com:80/~smith/home.html1160 <div id="rfc.figure.u.18"></div><pre class="text"> http://example.com:80/~smith/home.html 1188 1161 http://EXAMPLE.com/%7Esmith/home.html 1189 1162 http://EXAMPLE.com:/%7esmith/home.html … … 1202 1175 or invalid request method) and clients are implemented to only expect a response. 1203 1176 </p> 1204 <div id="rfc.figure.u. 22"></div><pre class="inline"><span id="rfc.iref.g.36"></span> <a href="#http.message" class="smpl">HTTP-message</a> = <a href="#http.message" class="smpl">start-line</a>1177 <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.28"></span> <a href="#http.message" class="smpl">HTTP-message</a> = <a href="#http.message" class="smpl">start-line</a> 1205 1178 *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> ) 1206 1179 <a href="#core.rules" class="smpl">CRLF</a> … … 1212 1185 Likewise, the presence of such whitespace in a response might be ignored by some clients or cause others to cease parsing. 1213 1186 </p> 1214 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="message.robustness" href="#message.robustness">Message Parsing Robustness</a></h2> 1215 <p id="rfc.section.3.1.p.1">In the interest of robustness, servers <em class="bcp14">SHOULD</em> ignore at least one empty line received where a Request-Line is expected. In other words, if the server is reading the protocol 1187 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="message.robustness" href="#message.robustness">Message Parsing and Robustness</a></h2> 1188 <p id="rfc.section.3.1.p.1">The normal procedure for parsing an HTTP message is to read the start-line into a structure, read each header field into a 1189 hash table by field name until the empty line, and then use the parsed data to determine if a message-body is expected. If 1190 a message-body has been indicated, then it is read as a stream until an amount of octets equal to the message-body length 1191 is read or the connection is closed. 1192 </p> 1193 <p id="rfc.section.3.1.p.2">Care must be taken to parse an HTTP message as a sequence of octets in an encoding that is a superset of US-ASCII. Attempting 1194 to parse HTTP as a stream of Unicode characters in a character encoding like UTF-16 might introduce security flaws due to 1195 the differing ways that such parsers interpret invalid characters. 1196 </p> 1197 <p id="rfc.section.3.1.p.3">Older HTTP/1.0 client implementations might send an extra CRLF after a POST request as a lame workaround for some early server 1198 applications that failed to read message-body content that was not terminated by a line-ending. An HTTP/1.1 client <em class="bcp14">MUST NOT</em> preface or follow a request with an extra CRLF. If terminating the request message-body with a line-ending is desired, then 1199 the client <em class="bcp14">MUST</em> include the terminating CRLF octets as part of the message-body length. 1200 </p> 1201 <p id="rfc.section.3.1.p.4">In the interest of robustness, servers <em class="bcp14">SHOULD</em> ignore at least one empty line received where a Request-Line is expected. In other words, if the server is reading the protocol 1216 1202 stream at the beginning of a message and receives a CRLF first, it <em class="bcp14">SHOULD</em> ignore the CRLF. Likewise, although the line terminator for the start-line and header fields is the sequence CRLF, we recommend 1217 1203 that recipients recognize a single LF as a line terminator and ignore any CR. 1218 1204 </p> 1219 <p id="rfc.section.3.1.p.2">Some old HTTP/1.0 client implementations send an extra CRLF after a POST request as a lame workaround for some early server 1220 applications that failed to read message-body content that was not terminated by a line-ending. An HTTP/1.1 client <em class="bcp14">MUST NOT</em> preface or follow a request with an extra CRLF. If terminating the request message-body with a line-ending is desired, then 1221 the client <em class="bcp14">MUST</em> include the terminating CRLF octets as part of the message-body length. 1222 </p> 1223 <p id="rfc.section.3.1.p.3">When a server listening only for HTTP request messages, or processing what appears from the start-line to be an HTTP request 1205 <p id="rfc.section.3.1.p.5">When a server listening only for HTTP request messages, or processing what appears from the start-line to be an HTTP request 1224 1206 message, receives a sequence of octets that does not match the HTTP-message grammar aside from the robustness exceptions listed 1225 1207 above, the server <em class="bcp14">MUST</em> respond with an HTTP/1.1 400 (Bad Request) response. 1226 </p>1227 <p id="rfc.section.3.1.p.4">The normal procedure for parsing an HTTP message is to read the start-line into a structure, read each header field into a1228 hash table by field name until the empty line, and then use the parsed data to determine if a message-body is expected. If1229 a message-body has been indicated, then it is read as a stream until an amount of octets equal to the message-body length1230 is read or the connection is closed. Care must be taken to parse an HTTP message as a sequence of octets in an encoding that1231 is a superset of US-ASCII. Attempting to parse HTTP as a stream of Unicode characters in a character encoding like UTF-161232 might introduce security flaws due to the differing ways that such parsers interpret invalid characters.1233 </p>1234 <p id="rfc.section.3.1.p.5">HTTP allows the set of defined header fields to be extended without changing the protocol version (see <a href="#header.field.registration" title="Header Field Registration">Section 10.1</a>). Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the proxy is specifically configured to block or otherwise transform such fields. Unrecognized1235 header fields <em class="bcp14">SHOULD</em> be ignored by other recipients.1236 1208 </p> 1237 1209 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="header.fields" href="#header.fields">Header Fields</a></h2> … … 1239 1211 value. 1240 1212 </p> 1241 <div id="rfc.figure.u.2 3"></div><pre class="inline"><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span> <a href="#header.fields" class="smpl">header-field</a> = <a href="#header.fields" class="smpl">field-name</a> ":" <a href="#rule.whitespace" class="smpl">OWS</a> [ <a href="#header.fields" class="smpl">field-value</a> ] <a href="#rule.whitespace" class="smpl">OWS</a>1213 <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span><span id="rfc.iref.g.32"></span> <a href="#header.fields" class="smpl">header-field</a> = <a href="#header.fields" class="smpl">field-name</a> ":" <a href="#rule.whitespace" class="smpl">OWS</a> [ <a href="#header.fields" class="smpl">field-value</a> ] <a href="#rule.whitespace" class="smpl">OWS</a> 1242 1214 <a href="#header.fields" class="smpl">field-name</a> = <a href="#rule.token.separators" class="smpl">token</a> 1243 1215 <a href="#header.fields" class="smpl">field-value</a> = *( <a href="#header.fields" class="smpl">field-content</a> / <a href="#rule.whitespace" class="smpl">OWS</a> ) 1244 1216 <a href="#header.fields" class="smpl">field-content</a> = *( <a href="#core.rules" class="smpl">WSP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> ) 1245 </pre><p id="rfc.section.3.2.p.3">No whitespace is allowed between the header field name and colon. For security reasons, any request message received containing 1246 such whitespace <em class="bcp14">MUST</em> be rejected with a response code of 400 (Bad Request). A proxy <em class="bcp14">MUST</em> remove any such whitespace from a response message before forwarding the message downstream. 1247 </p> 1248 <p id="rfc.section.3.2.p.4">A field value <em class="bcp14">MAY</em> be preceded by optional whitespace (OWS); a single SP is preferred. The field value does not include any leading or trailing 1249 white space: OWS occurring before the first non-whitespace octet of the field value or after the last non-whitespace octet 1250 of the field value is ignored and <em class="bcp14">SHOULD</em> be removed before further processing (as this does not change the meaning of the header field). 1251 </p> 1252 <p id="rfc.section.3.2.p.5">The order in which header fields with differing field names are received is not significant. However, it is "good practice" 1217 </pre><p id="rfc.section.3.2.p.3">The field-name token labels the corresponding field-value as having the semantics defined by that header field. For example, 1218 the Date header field is defined in <a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section 9.3</a> as containing the origination timestamp for the message in which it appears. 1219 </p> 1220 <p id="rfc.section.3.2.p.4">HTTP header fields are fully extensible: there is no limit on the introduction of new field names, each presumably defining 1221 new semantics, or on the number of header fields used in a given message. Existing fields are defined in each part of this 1222 specification and in many other specifications outside the standards process. New header fields can be introduced without 1223 changing the protocol version if their defined semantics allow them to be safely ignored by recipients that do not recognize 1224 them. 1225 </p> 1226 <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA according to the procedures in <a href="#header.field.registration" title="Header Field Registration">Section 10.1</a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 9.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients. 1227 </p> 1228 <p id="rfc.section.3.2.p.6">The order in which header fields with differing field names are received is not significant. However, it is "good practice" 1253 1229 to send header fields that contain control data first, such as Host on requests and Date on responses, so that implementations 1254 1230 can decide when not to handle a message as early as possible. A server <em class="bcp14">MUST</em> wait until the entire header section is received before interpreting a request message, since later header fields might include 1255 1231 conditionals, authentication credentials, or deliberately misleading duplicate header fields that would impact request processing. 1256 1232 </p> 1257 <p id="rfc.section.3.2.p. 6">Multiple header fields with the same field name <em class="bcp14">MUST NOT</em> be sent in a message unless the entire field value for that header field is defined as a comma-separated list [i.e., #(values)].1233 <p id="rfc.section.3.2.p.7">Multiple header fields with the same field name <em class="bcp14">MUST NOT</em> be sent in a message unless the entire field value for that header field is defined as a comma-separated list [i.e., #(values)]. 1258 1234 Multiple header fields with the same field name can be combined into one "field-name: field-value" pair, without changing 1259 1235 the semantics of the message, by appending each subsequent field value to the combined field value in order, separated by … … 1261 1237 of the combined field value; a proxy <em class="bcp14">MUST NOT</em> change the order of these field values when forwarding a message. 1262 1238 </p> 1263 <div class="note" id="rfc.section.3.2.p. 7">1239 <div class="note" id="rfc.section.3.2.p.8"> 1264 1240 <p> <b>Note:</b> The "Set-Cookie" header field as implemented in practice can occur multiple times, but does not use the list syntax, and thus 1265 1241 cannot be combined into a single line (<a href="#RFC6265" id="rfc.xref.RFC6265.2"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a>). (See Appendix A.2.3 of <a href="#Kri2001" id="rfc.xref.Kri2001.1"><cite title="HTTP Cookies: Standards, Privacy, and Politics">[Kri2001]</cite></a> for details.) Also note that the Set-Cookie2 header field specified in <a href="#RFC2965" id="rfc.xref.RFC2965.1"><cite title="HTTP State Management Mechanism">[RFC2965]</cite></a> does not share this problem. 1266 1242 </p> 1267 1243 </div> 1268 <p id="rfc.section.3.2.p.8">Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one 1244 <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> <a id="field.parsing" href="#field.parsing">Field Parsing</a></h3> 1245 <p id="rfc.section.3.2.1.p.1">No whitespace is allowed between the header field-name and colon. In the past, differences in the handling of such whitespace 1246 have led to security vulnerabilities in request routing and response handling. Any received request message that contains 1247 whitespace between a header field-name and colon <em class="bcp14">MUST</em> be rejected with a response code of 400 (Bad Request). A proxy <em class="bcp14">MUST</em> remove any such whitespace from a response message before forwarding the message downstream. 1248 </p> 1249 <p id="rfc.section.3.2.1.p.2">A field value <em class="bcp14">MAY</em> be preceded by optional whitespace (OWS); a single SP is preferred. The field value does not include any leading or trailing 1250 white space: OWS occurring before the first non-whitespace octet of the field value or after the last non-whitespace octet 1251 of the field value is ignored and <em class="bcp14">SHOULD</em> be removed before further processing (as this does not change the meaning of the header field). 1252 </p> 1253 <p id="rfc.section.3.2.1.p.3">Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one 1269 1254 space or horizontal tab octet (line folding). This specification deprecates such line folding except within the message/http 1270 media type (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section 10.3.1</a>). HTTP/1.1 senders <em class="bcp14">MUST NOT</em> produce messages that include line folding (i.e., that contain any field-content that matches the obs-fold rule) unless the 1271 message is intended for packaging within the message/http media type. HTTP/1.1 recipients <em class="bcp14">SHOULD</em> accept line folding and replace any embedded obs-fold whitespace with a single SP prior to interpreting the field value or 1272 forwarding the message downstream. 1273 </p> 1274 <p id="rfc.section.3.2.p.9">Historically, HTTP has allowed field content with text in the ISO-8859-1 <a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a> character encoding and supported other character sets only through use of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a> encoding. In practice, most HTTP header field values use only a subset of the US-ASCII character encoding <a href="#USASCII" id="rfc.xref.USASCII.2"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>. Newly defined header fields <em class="bcp14">SHOULD</em> limit their field values to US-ASCII octets. Recipients <em class="bcp14">SHOULD</em> treat other (obs-text) octets in field content as opaque data. 1255 media type (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section 10.3.1</a>). HTTP senders <em class="bcp14">MUST NOT</em> produce messages that include line folding (i.e., that contain any field-content that matches the obs-fold rule) unless the 1256 message is intended for packaging within the message/http media type. HTTP recipients <em class="bcp14">SHOULD</em> accept line folding and replace any embedded obs-fold whitespace with either a single SP or a matching number of SP octets 1257 (to avoid buffer copying) prior to interpreting the field value or forwarding the message downstream. 1258 </p> 1259 <p id="rfc.section.3.2.1.p.4">Historically, HTTP has allowed field content with text in the ISO-8859-1 <a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a> character encoding and supported other character sets only through use of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a> encoding. In practice, most HTTP header field values use only a subset of the US-ASCII character encoding <a href="#USASCII" id="rfc.xref.USASCII.2"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>. Newly defined header fields <em class="bcp14">SHOULD</em> limit their field values to US-ASCII octets. Recipients <em class="bcp14">SHOULD</em> treat other (obs-text) octets in field content as opaque data. 1260 </p> 1261 <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a> <a id="field.length" href="#field.length">Field Length</a></h3> 1262 <p id="rfc.section.3.2.2.p.1">HTTP does not place a pre-defined limit on the length of header fields, either in isolation or as a set. A server <em class="bcp14">MUST</em> be prepared to receive request header fields of unbounded length and respond with a 4xx status code if the received header 1263 field(s) would be longer than the server wishes to handle. 1264 </p> 1265 <p id="rfc.section.3.2.2.p.2">A client that receives response headers that are longer than it wishes to handle can only treat it as a server error.</p> 1266 <p id="rfc.section.3.2.2.p.3">Various ad-hoc limitations on header length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support messages whose combined header fields have 4000 or more octets. 1267 </p> 1268 <h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a> <a id="field.rules" href="#field.rules">Common Field ABNF Rules</a></h3> 1269 <div id="rule.token.separators"> 1270 <p id="rfc.section.3.2.3.p.1"> Many HTTP/1.1 header field values consist of words (token or quoted-string) separated by whitespace or special characters. 1271 These special characters <em class="bcp14">MUST</em> be in a quoted string to be used within a parameter value (as defined in <a href="#transfer.codings" title="Transfer Codings">Section 6.2</a>). 1272 </p> 1273 </div> 1274 <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.33"></span><span id="rfc.iref.g.34"></span><span id="rfc.iref.g.35"></span><span id="rfc.iref.g.36"></span> <a href="#rule.token.separators" class="smpl">word</a> = <a href="#rule.token.separators" class="smpl">token</a> / <a href="#rule.quoted-string" class="smpl">quoted-string</a> 1275 1276 <a href="#rule.token.separators" class="smpl">token</a> = 1*<a href="#rule.token.separators" class="smpl">tchar</a> 1277 1278 <a href="#rule.token.separators" class="smpl">tchar</a> = "!" / "#" / "$" / "%" / "&" / "'" / "*" 1279 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" 1280 / <a href="#core.rules" class="smpl">DIGIT</a> / <a href="#core.rules" class="smpl">ALPHA</a> 1281 ; any <a href="#core.rules" class="smpl">VCHAR</a>, except <a href="#rule.token.separators" class="smpl">special</a> 1282 1283 <a href="#rule.token.separators" class="smpl">special</a> = "(" / ")" / "<" / ">" / "@" / "," 1284 / ";" / ":" / "\" / DQUOTE / "/" / "[" 1285 / "]" / "?" / "=" / "{" / "}" 1286 </pre><div id="rule.quoted-string"> 1287 <p id="rfc.section.3.2.3.p.3"> A string of text is parsed as a single word if it is quoted using double-quote marks.</p> 1288 </div> 1289 <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span> <a href="#rule.quoted-string" class="smpl">quoted-string</a> = <a href="#core.rules" class="smpl">DQUOTE</a> *( <a href="#rule.quoted-string" class="smpl">qdtext</a> / <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> ) <a href="#core.rules" class="smpl">DQUOTE</a> 1290 <a href="#rule.quoted-string" class="smpl">qdtext</a> = <a href="#rule.whitespace" class="smpl">OWS</a> / %x21 / %x23-5B / %x5D-7E / <a href="#rule.quoted-string" class="smpl">obs-text</a> 1291 <a href="#rule.quoted-string" class="smpl">obs-text</a> = %x80-FF 1292 </pre><div id="rule.quoted-pair"> 1293 <p id="rfc.section.3.2.3.p.5"> The backslash octet ("\") can be used as a single-octet quoting mechanism within quoted-string constructs:</p> 1294 </div> 1295 <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.40"></span> <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> = "\" ( <a href="#core.rules" class="smpl">WSP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> ) 1296 </pre><p id="rfc.section.3.2.3.p.7">Recipients that process the value of the quoted-string <em class="bcp14">MUST</em> handle a quoted-pair as if it were replaced by the octet following the backslash. 1297 </p> 1298 <p id="rfc.section.3.2.3.p.8">Senders <em class="bcp14">SHOULD NOT</em> escape octets in quoted-strings that do not require escaping (i.e., other than DQUOTE and the backslash octet). 1275 1299 </p> 1276 1300 <div id="rule.comment"> 1277 <p id="rfc.section.3.2. p.10"> Comments can be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed1301 <p id="rfc.section.3.2.3.p.9"> Comments can be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed 1278 1302 in fields containing "comment" as part of their field value definition. 1279 1303 </p> … … 1281 1305 <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span> <a href="#rule.comment" class="smpl">comment</a> = "(" *( <a href="#rule.comment" class="smpl">ctext</a> / <a href="#rule.quoted-cpair" class="smpl">quoted-cpair</a> / <a href="#rule.comment" class="smpl">comment</a> ) ")" 1282 1306 <a href="#rule.comment" class="smpl">ctext</a> = <a href="#rule.whitespace" class="smpl">OWS</a> / %x21-27 / %x2A-5B / %x5D-7E / <a href="#rule.quoted-string" class="smpl">obs-text</a> 1283 ; <a href="#rule.whitespace" class="smpl">OWS</a> / <<a href="#core.rules" class="smpl">VCHAR</a> except "(", ")", and "\"> / <a href="#rule.quoted-string" class="smpl">obs-text</a>1284 1307 </pre><div id="rule.quoted-cpair"> 1285 <p id="rfc.section.3.2. p.12"> The backslash octet ("\") can be used as a single-octet quoting mechanism within comment constructs:</p>1308 <p id="rfc.section.3.2.3.p.11"> The backslash octet ("\") can be used as a single-octet quoting mechanism within comment constructs:</p> 1286 1309 </div> 1287 1310 <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.43"></span> <a href="#rule.quoted-cpair" class="smpl">quoted-cpair</a> = "\" ( <a href="#core.rules" class="smpl">WSP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> ) 1288 </pre><p id="rfc.section.3.2.p.14">Senders <em class="bcp14">SHOULD NOT</em> escape octets that do not require escaping (i.e., other than the backslash octet "\" and the parentheses "(" and ")"). 1289 </p> 1290 <p id="rfc.section.3.2.p.15">HTTP does not place a pre-defined limit on the length of header fields, either in isolation or as a set. A server <em class="bcp14">MUST</em> be prepared to receive request header fields of unbounded length and respond with a 4xx status code if the received header 1291 field(s) would be longer than the server wishes to handle. 1292 </p> 1293 <p id="rfc.section.3.2.p.16">A client that receives response headers that are longer than it wishes to handle can only treat it as a server error.</p> 1294 <p id="rfc.section.3.2.p.17">Various ad-hoc limitations on header length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support messages whose combined header fields have 4000 or more octets. 1311 </pre><p id="rfc.section.3.2.3.p.13">Senders <em class="bcp14">SHOULD NOT</em> escape octets in comments that do not require escaping (i.e., other than the backslash octet "\" and the parentheses "(" and 1312 ")"). 1295 1313 </p> 1296 1314 <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="message.body" href="#message.body">Message Body</a></h2> … … 1413 1431 <tr> 1414 1432 <td class="left">Connection</td> 1415 <td class="left"><a href="#header.connection" id="rfc.xref.header.connection. 3" title="Connection">Section 9.1</a></td>1433 <td class="left"><a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section 9.1</a></td> 1416 1434 </tr> 1417 1435 <tr> 1418 1436 <td class="left">Date</td> 1419 <td class="left"><a href="#header.date" id="rfc.xref.header.date. 1" title="Date">Section 9.3</a></td>1437 <td class="left"><a href="#header.date" id="rfc.xref.header.date.2" title="Date">Section 9.3</a></td> 1420 1438 </tr> 1421 1439 <tr> … … 1893 1911 </p> 1894 1912 <p id="rfc.section.7.1.2.p.2">Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling 1895 takes place using the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection. 4" title="Connection">Section 9.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection.1913 takes place using the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.5" title="Connection">Section 9.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection. 1896 1914 </p> 1897 1915 <h4 id="rfc.section.7.1.2.1"><a href="#rfc.section.7.1.2.1">7.1.2.1</a> <a id="persistent.negotiation" href="#persistent.negotiation">Negotiation</a></h4> … … 1919 1937 </p> 1920 1938 <h3 id="rfc.section.7.1.3"><a href="#rfc.section.7.1.3">7.1.3</a> <a id="persistent.proxy" href="#persistent.proxy">Proxy Servers</a></h3> 1921 <p id="rfc.section.7.1.3.p.1">It is especially important that proxies correctly implement the properties of the Connection header field as specified in <a href="#header.connection" id="rfc.xref.header.connection. 5" title="Connection">Section 9.1</a>.1939 <p id="rfc.section.7.1.3.p.1">It is especially important that proxies correctly implement the properties of the Connection header field as specified in <a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section 9.1</a>. 1922 1940 </p> 1923 1941 <p id="rfc.section.7.1.3.p.2">The proxy server <em class="bcp14">MUST</em> signal persistent connections separately with its clients and the origin servers (or other proxy servers) that it connects … … 1948 1966 </ul> 1949 1967 <p id="rfc.section.7.1.3.1.p.3">All other header fields defined by HTTP/1.1 are end-to-end header fields.</p> 1950 <p id="rfc.section.7.1.3.1.p.4">Other hop-by-hop header fields <em class="bcp14">MUST</em> be listed in a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection. 6" title="Connection">Section 9.1</a>).1968 <p id="rfc.section.7.1.3.1.p.4">Other hop-by-hop header fields <em class="bcp14">MUST</em> be listed in a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section 9.1</a>). 1951 1969 </p> 1952 1970 <h4 id="rfc.section.7.1.3.2"><a href="#rfc.section.7.1.3.2">7.1.3.2</a> <a id="non-modifiable.header-fields" href="#non-modifiable.header-fields">Non-modifiable Header Fields</a></h4> … … 2272 2290 TE: 2273 2291 TE: trailers, deflate;q=0.5 2274 </pre><p id="rfc.section.9.5.p.7">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection. 7" title="Connection">Section 9.1</a>) whenever TE is present in an HTTP/1.1 message.2292 </pre><p id="rfc.section.9.5.p.7">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section 9.1</a>) whenever TE is present in an HTTP/1.1 message. 2275 2293 </p> 2276 2294 <p id="rfc.section.9.5.p.8">A server tests whether a transfer-coding is acceptable, according to a TE field, using these rules: </p> … … 2354 2372 although the first action after changing the protocol <em class="bcp14">MUST</em> be a response to the initial HTTP request containing the Upgrade header field. 2355 2373 </p> 2356 <p id="rfc.section.9.8.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection. 8" title="Connection">Section 9.1</a>) whenever Upgrade is present in an HTTP/1.1 message.2374 <p id="rfc.section.9.8.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section 9.1</a>) whenever Upgrade is present in an HTTP/1.1 message. 2357 2375 </p> 2358 2376 <p id="rfc.section.9.8.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it … … 2453 2471 <td class="left">http</td> 2454 2472 <td class="left">standard</td> 2455 <td class="left"> <a href="#header.connection" id="rfc.xref.header.connection. 9" title="Connection">Section 9.1</a>2473 <td class="left"> <a href="#header.connection" id="rfc.xref.header.connection.10" title="Connection">Section 9.1</a> 2456 2474 </td> 2457 2475 </tr> … … 2467 2485 <td class="left">http</td> 2468 2486 <td class="left">standard</td> 2469 <td class="left"> <a href="#header.date" id="rfc.xref.header.date. 2" title="Date">Section 9.3</a>2487 <td class="left"> <a href="#header.date" id="rfc.xref.header.date.3" title="Date">Section 9.3</a> 2470 2488 </td> 2471 2489 </tr> … … 2516 2534 </div> 2517 2535 <p id="rfc.section.10.1.p.2">Furthermore, the header field name "Close" shall be registered as "reserved", as its use as HTTP header field would be in 2518 conflict with the use of the "close" connection option for the "Connection" header field (<a href="#header.connection" id="rfc.xref.header.connection.1 0" title="Connection">Section 9.1</a>).2536 conflict with the use of the "close" connection option for the "Connection" header field (<a href="#header.connection" id="rfc.xref.header.connection.11" title="Connection">Section 9.1</a>). 2519 2537 </p> 2520 2538 <div id="rfc.table.u.2"> … … 3061 3079 Therefore, we need some other mechanism for indicating a persistent connection is desired, which is safe to use even when 3062 3080 talking to an old proxy that ignores Connection. Persistent connections are the default for HTTP/1.1 messages; we introduce 3063 a new keyword (Connection: close) for declaring non-persistence. See <a href="#header.connection" id="rfc.xref.header.connection.1 1" title="Connection">Section 9.1</a>.3081 a new keyword (Connection: close) for declaring non-persistence. See <a href="#header.connection" id="rfc.xref.header.connection.12" title="Connection">Section 9.1</a>. 3064 3082 </p> 3065 3083 <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2> … … 3090 3108 <p id="rfc.section.A.2.p.10">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section 9</a>) 3091 3109 </p> 3092 <p id="rfc.section.A.2.p.11">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.1 2" title="Connection">Section 9.1</a>)3110 <p id="rfc.section.A.2.p.11">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.13" title="Connection">Section 9.1</a>) 3093 3111 </p> 3094 3112 <p id="rfc.section.A.2.p.12">Define the semantics of the "Upgrade" header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section 9.8</a>) … … 3658 3676 <li>compress (Coding Format) <a href="#rfc.iref.c.8">6.2.2.1</a></li> 3659 3677 <li>connection <a href="#rfc.iref.c.2"><b>2.1</b></a></li> 3660 <li>Connection header field <a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3. 5</a>, <a href="#rfc.xref.header.connection.4">7.1.2</a>, <a href="#rfc.xref.header.connection.5">7.1.3</a>, <a href="#rfc.xref.header.connection.6">7.1.3.1</a>, <a href="#rfc.iref.c.12"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.7">9.5</a>, <a href="#rfc.xref.header.connection.8">9.8</a>, <a href="#rfc.xref.header.connection.9">10.1</a>, <a href="#rfc.xref.header.connection.10">10.1</a>, <a href="#rfc.xref.header.connection.11">A.1.2</a>, <a href="#rfc.xref.header.connection.12">A.2</a></li>3678 <li>Connection header field <a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">3.5</a>, <a href="#rfc.xref.header.connection.5">7.1.2</a>, <a href="#rfc.xref.header.connection.6">7.1.3</a>, <a href="#rfc.xref.header.connection.7">7.1.3.1</a>, <a href="#rfc.iref.c.12"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.8">9.5</a>, <a href="#rfc.xref.header.connection.9">9.8</a>, <a href="#rfc.xref.header.connection.10">10.1</a>, <a href="#rfc.xref.header.connection.11">10.1</a>, <a href="#rfc.xref.header.connection.12">A.1.2</a>, <a href="#rfc.xref.header.connection.13">A.2</a></li> 3661 3679 <li>Content-Length header field <a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.iref.c.13"><b>9.2</b></a>, <a href="#rfc.xref.header.content-length.2">10.1</a></li> 3662 3680 </ul> 3663 3681 </li> 3664 3682 <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul> 3665 <li>Date header field <a href="#rfc.xref.header.date.1">3. 5</a>, <a href="#rfc.iref.d.3"><b>9.3</b></a>, <a href="#rfc.xref.header.date.2">10.1</a></li>3683 <li>Date header field <a href="#rfc.xref.header.date.1">3.2</a>, <a href="#rfc.xref.header.date.2">3.5</a>, <a href="#rfc.iref.d.3"><b>9.3</b></a>, <a href="#rfc.xref.header.date.3">10.1</a></li> 3666 3684 <li>deflate (Coding Format) <a href="#rfc.iref.d.2">6.2.2.2</a></li> 3667 3685 <li>downstream <a href="#rfc.iref.d.1"><b>2.4</b></a></li> … … 3673 3691 </li> 3674 3692 <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul> 3675 <li>gateway <a href="#rfc.iref.g. 24"><b>2.4</b></a></li>3693 <li>gateway <a href="#rfc.iref.g.16"><b>2.4</b></a></li> 3676 3694 <li><tt>Grammar</tt> 3677 3695 <ul> 3678 <li><tt>absolute-URI</tt> <a href="#rfc.iref.g.2 8"><b>2.7</b></a></li>3696 <li><tt>absolute-URI</tt> <a href="#rfc.iref.g.20"><b>2.7</b></a></li> 3679 3697 <li>ALPHA <a href="#rfc.iref.g.1"><b>1.2</b></a></li> 3680 3698 <li><tt>asctime-date</tt> <a href="#rfc.iref.g.68"><b>6.1</b></a></li> 3681 3699 <li><tt>attribute</tt> <a href="#rfc.iref.g.72"><b>6.2</b></a></li> 3682 <li><tt>authority</tt> <a href="#rfc.iref.g.2 9"><b>2.7</b></a></li>3700 <li><tt>authority</tt> <a href="#rfc.iref.g.21"><b>2.7</b></a></li> 3683 3701 <li><tt>BWS</tt> <a href="#rfc.iref.g.15"><b>1.2.2</b></a></li> 3684 3702 <li><tt>chunk</tt> <a href="#rfc.iref.g.77"><b>6.2.1</b></a></li> … … 3689 3707 <li><tt>chunk-size</tt> <a href="#rfc.iref.g.78"><b>6.2.1</b></a></li> 3690 3708 <li><tt>Chunked-Body</tt> <a href="#rfc.iref.g.76"><b>6.2.1</b></a></li> 3691 <li><tt>comment</tt> <a href="#rfc.iref.g.41"><b>3.2 </b></a></li>3709 <li><tt>comment</tt> <a href="#rfc.iref.g.41"><b>3.2.3</b></a></li> 3692 3710 <li><tt>Connection</tt> <a href="#rfc.iref.g.91"><b>9.1</b></a></li> 3693 3711 <li><tt>connection-token</tt> <a href="#rfc.iref.g.92"><b>9.1</b></a></li> … … 3695 3713 <li>CR <a href="#rfc.iref.g.2"><b>1.2</b></a></li> 3696 3714 <li>CRLF <a href="#rfc.iref.g.3"><b>1.2</b></a></li> 3697 <li><tt>ctext</tt> <a href="#rfc.iref.g.42"><b>3.2 </b></a></li>3715 <li><tt>ctext</tt> <a href="#rfc.iref.g.42"><b>3.2.3</b></a></li> 3698 3716 <li>CTL <a href="#rfc.iref.g.4"><b>1.2</b></a></li> 3699 3717 <li><tt>Date</tt> <a href="#rfc.iref.g.94"><b>9.3</b></a></li> … … 3706 3724 <li>DIGIT <a href="#rfc.iref.g.5"><b>1.2</b></a></li> 3707 3725 <li>DQUOTE <a href="#rfc.iref.g.6"><b>1.2</b></a></li> 3708 <li><tt>field-content</tt> <a href="#rfc.iref.g. 40"><b>3.2</b></a></li>3709 <li><tt>field-name</tt> <a href="#rfc.iref.g.3 8"><b>3.2</b></a></li>3710 <li><tt>field-value</tt> <a href="#rfc.iref.g.3 9"><b>3.2</b></a></li>3726 <li><tt>field-content</tt> <a href="#rfc.iref.g.32"><b>3.2</b></a></li> 3727 <li><tt>field-name</tt> <a href="#rfc.iref.g.30"><b>3.2</b></a></li> 3728 <li><tt>field-value</tt> <a href="#rfc.iref.g.31"><b>3.2</b></a></li> 3711 3729 <li><tt>GMT</tt> <a href="#rfc.iref.g.65"><b>6.1</b></a></li> 3712 <li><tt>header-field</tt> <a href="#rfc.iref.g. 37"><b>3.2</b></a></li>3730 <li><tt>header-field</tt> <a href="#rfc.iref.g.29"><b>3.2</b></a></li> 3713 3731 <li>HEXDIG <a href="#rfc.iref.g.7"><b>1.2</b></a></li> 3714 3732 <li><tt>Host</tt> <a href="#rfc.iref.g.95"><b>9.4</b></a></li> 3715 3733 <li><tt>hour</tt> <a href="#rfc.iref.g.57"><b>6.1</b></a></li> 3716 3734 <li><tt>HTTP-date</tt> <a href="#rfc.iref.g.53"><b>6.1</b></a></li> 3717 <li><tt>HTTP-message</tt> <a href="#rfc.iref.g. 36"><b>3</b></a></li>3718 <li><tt>HTTP-Prot-Name</tt> <a href="#rfc.iref.g. 26"><b>2.6</b></a></li>3719 <li><tt>http-URI</tt> <a href="#rfc.iref.g. 34"><b>2.7.1</b></a></li>3720 <li><tt>HTTP-Version</tt> <a href="#rfc.iref.g. 25"><b>2.6</b></a></li>3721 <li><tt>https-URI</tt> <a href="#rfc.iref.g. 35"><b>2.7.2</b></a></li>3735 <li><tt>HTTP-message</tt> <a href="#rfc.iref.g.28"><b>3</b></a></li> 3736 <li><tt>HTTP-Prot-Name</tt> <a href="#rfc.iref.g.18"><b>2.6</b></a></li> 3737 <li><tt>http-URI</tt> <a href="#rfc.iref.g.26"><b>2.7.1</b></a></li> 3738 <li><tt>HTTP-Version</tt> <a href="#rfc.iref.g.17"><b>2.6</b></a></li> 3739 <li><tt>https-URI</tt> <a href="#rfc.iref.g.27"><b>2.7.2</b></a></li> 3722 3740 <li><tt>last-chunk</tt> <a href="#rfc.iref.g.79"><b>6.2.1</b></a></li> 3723 3741 <li>LF <a href="#rfc.iref.g.8"><b>1.2</b></a></li> … … 3727 3745 <li><tt>month</tt> <a href="#rfc.iref.g.63"><b>6.1</b></a></li> 3728 3746 <li><tt>obs-date</tt> <a href="#rfc.iref.g.66"><b>6.1</b></a></li> 3729 <li><tt>obs-text</tt> <a href="#rfc.iref.g. 22"><b>1.2.2</b></a></li>3747 <li><tt>obs-text</tt> <a href="#rfc.iref.g.39"><b>3.2.3</b></a></li> 3730 3748 <li>OCTET <a href="#rfc.iref.g.9"><b>1.2</b></a></li> 3731 3749 <li><tt>OWS</tt> <a href="#rfc.iref.g.13"><b>1.2.2</b></a></li> 3732 <li><tt>path-absolute</tt> <a href="#rfc.iref.g. 30"><b>2.7</b></a></li>3733 <li><tt>port</tt> <a href="#rfc.iref.g. 31"><b>2.7</b></a></li>3750 <li><tt>path-absolute</tt> <a href="#rfc.iref.g.22"><b>2.7</b></a></li> 3751 <li><tt>port</tt> <a href="#rfc.iref.g.23"><b>2.7</b></a></li> 3734 3752 <li><tt>product</tt> <a href="#rfc.iref.g.88"><b>6.3</b></a></li> 3735 3753 <li><tt>product-version</tt> <a href="#rfc.iref.g.89"><b>6.3</b></a></li> … … 3737 3755 <li><tt>protocol-version</tt> <a href="#rfc.iref.g.106"><b>9.9</b></a></li> 3738 3756 <li><tt>pseudonym</tt> <a href="#rfc.iref.g.108"><b>9.9</b></a></li> 3739 <li><tt>qdtext</tt> <a href="#rfc.iref.g. 21"><b>1.2.2</b></a></li>3757 <li><tt>qdtext</tt> <a href="#rfc.iref.g.38"><b>3.2.3</b></a></li> 3740 3758 <li><tt>qdtext-nf</tt> <a href="#rfc.iref.g.86"><b>6.2.1</b></a></li> 3741 <li><tt>query</tt> <a href="#rfc.iref.g. 32"><b>2.7</b></a></li>3742 <li><tt>quoted-cpair</tt> <a href="#rfc.iref.g.43"><b>3.2 </b></a></li>3743 <li><tt>quoted-pair</tt> <a href="#rfc.iref.g. 23"><b>1.2.2</b></a></li>3759 <li><tt>query</tt> <a href="#rfc.iref.g.24"><b>2.7</b></a></li> 3760 <li><tt>quoted-cpair</tt> <a href="#rfc.iref.g.43"><b>3.2.3</b></a></li> 3761 <li><tt>quoted-pair</tt> <a href="#rfc.iref.g.40"><b>3.2.3</b></a></li> 3744 3762 <li><tt>quoted-str-nf</tt> <a href="#rfc.iref.g.85"><b>6.2.1</b></a></li> 3745 <li><tt>quoted-string</tt> <a href="#rfc.iref.g. 20"><b>1.2.2</b></a></li>3763 <li><tt>quoted-string</tt> <a href="#rfc.iref.g.37"><b>3.2.3</b></a></li> 3746 3764 <li><tt>qvalue</tt> <a href="#rfc.iref.g.90"><b>6.4</b></a></li> 3747 3765 <li><tt>Reason-Phrase</tt> <a href="#rfc.iref.g.52"><b>5.1.1</b></a></li> … … 3757 3775 <li><tt>second</tt> <a href="#rfc.iref.g.59"><b>6.1</b></a></li> 3758 3776 <li>SP <a href="#rfc.iref.g.10"><b>1.2</b></a></li> 3759 <li><tt>special</tt> <a href="#rfc.iref.g. 19"><b>1.2.2</b></a></li>3777 <li><tt>special</tt> <a href="#rfc.iref.g.36"><b>3.2.3</b></a></li> 3760 3778 <li><tt>Status-Code</tt> <a href="#rfc.iref.g.51"><b>5.1.1</b></a></li> 3761 3779 <li><tt>Status-Line</tt> <a href="#rfc.iref.g.50"><b>5.1</b></a></li> 3762 3780 <li><tt>t-codings</tt> <a href="#rfc.iref.g.97"><b>9.5</b></a></li> 3763 <li><tt>tchar</tt> <a href="#rfc.iref.g. 18"><b>1.2.2</b></a></li>3781 <li><tt>tchar</tt> <a href="#rfc.iref.g.35"><b>3.2.3</b></a></li> 3764 3782 <li><tt>TE</tt> <a href="#rfc.iref.g.96"><b>9.5</b></a></li> 3765 3783 <li><tt>te-ext</tt> <a href="#rfc.iref.g.99"><b>9.5</b></a></li> 3766 3784 <li><tt>te-params</tt> <a href="#rfc.iref.g.98"><b>9.5</b></a></li> 3767 3785 <li><tt>time-of-day</tt> <a href="#rfc.iref.g.56"><b>6.1</b></a></li> 3768 <li><tt>token</tt> <a href="#rfc.iref.g. 17"><b>1.2.2</b></a></li>3786 <li><tt>token</tt> <a href="#rfc.iref.g.34"><b>3.2.3</b></a></li> 3769 3787 <li><tt>Trailer</tt> <a href="#rfc.iref.g.100"><b>9.6</b></a></li> 3770 3788 <li><tt>trailer-part</tt> <a href="#rfc.iref.g.84"><b>6.2.1</b></a></li> … … 3774 3792 <li><tt>transfer-parameter</tt> <a href="#rfc.iref.g.71"><b>6.2</b></a></li> 3775 3793 <li><tt>Upgrade</tt> <a href="#rfc.iref.g.102"><b>9.8</b></a></li> 3776 <li><tt>uri-host</tt> <a href="#rfc.iref.g. 33"><b>2.7</b></a></li>3777 <li><tt>URI-reference</tt> <a href="#rfc.iref.g. 27"><b>2.7</b></a></li>3794 <li><tt>uri-host</tt> <a href="#rfc.iref.g.25"><b>2.7</b></a></li> 3795 <li><tt>URI-reference</tt> <a href="#rfc.iref.g.19"><b>2.7</b></a></li> 3778 3796 <li><tt>value</tt> <a href="#rfc.iref.g.73"><b>6.2</b></a></li> 3779 3797 <li>VCHAR <a href="#rfc.iref.g.11"><b>1.2</b></a></li> 3780 3798 <li><tt>Via</tt> <a href="#rfc.iref.g.103"><b>9.9</b></a></li> 3781 <li><tt>word</tt> <a href="#rfc.iref.g. 16"><b>1.2.2</b></a></li>3799 <li><tt>word</tt> <a href="#rfc.iref.g.33"><b>3.2.3</b></a></li> 3782 3800 <li>WSP <a href="#rfc.iref.g.12"><b>1.2</b></a></li> 3783 3801 <li><tt>year</tt> <a href="#rfc.iref.g.64"><b>6.1</b></a></li> … … 3791 3809 <li>Header Fields 3792 3810 <ul> 3793 <li>Connection <a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3. 5</a>, <a href="#rfc.xref.header.connection.4">7.1.2</a>, <a href="#rfc.xref.header.connection.5">7.1.3</a>, <a href="#rfc.xref.header.connection.6">7.1.3.1</a>, <a href="#rfc.iref.h.6"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.7">9.5</a>, <a href="#rfc.xref.header.connection.8">9.8</a>, <a href="#rfc.xref.header.connection.9">10.1</a>, <a href="#rfc.xref.header.connection.10">10.1</a>, <a href="#rfc.xref.header.connection.11">A.1.2</a>, <a href="#rfc.xref.header.connection.12">A.2</a></li>3811 <li>Connection <a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">3.5</a>, <a href="#rfc.xref.header.connection.5">7.1.2</a>, <a href="#rfc.xref.header.connection.6">7.1.3</a>, <a href="#rfc.xref.header.connection.7">7.1.3.1</a>, <a href="#rfc.iref.h.6"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.8">9.5</a>, <a href="#rfc.xref.header.connection.9">9.8</a>, <a href="#rfc.xref.header.connection.10">10.1</a>, <a href="#rfc.xref.header.connection.11">10.1</a>, <a href="#rfc.xref.header.connection.12">A.1.2</a>, <a href="#rfc.xref.header.connection.13">A.2</a></li> 3794 3812 <li>Content-Length <a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.iref.h.7"><b>9.2</b></a>, <a href="#rfc.xref.header.content-length.2">10.1</a></li> 3795 <li>Date <a href="#rfc.xref.header.date.1">3. 5</a>, <a href="#rfc.iref.h.8"><b>9.3</b></a>, <a href="#rfc.xref.header.date.2">10.1</a></li>3813 <li>Date <a href="#rfc.xref.header.date.1">3.2</a>, <a href="#rfc.xref.header.date.2">3.5</a>, <a href="#rfc.iref.h.8"><b>9.3</b></a>, <a href="#rfc.xref.header.date.3">10.1</a></li> 3796 3814 <li>Host <a href="#rfc.xref.header.host.1">4.3</a>, <a href="#rfc.iref.h.10"><b>9.4</b></a>, <a href="#rfc.xref.header.host.2">10.1</a>, <a href="#rfc.xref.header.host.3">A.1.1</a></li> 3797 3815 <li>TE <a href="#rfc.xref.header.te.1">6.2</a>, <a href="#rfc.xref.header.te.2">6.2.1</a>, <a href="#rfc.xref.header.te.3">6.4</a>, <a href="#rfc.iref.h.11"><b>9.5</b></a>, <a href="#rfc.xref.header.te.4">10.1</a></li> … … 3813 3831 <li>interception proxy <a href="#rfc.iref.i.3"><b>2.4</b></a></li> 3814 3832 <li>intermediary <a href="#rfc.iref.i.1"><b>2.4</b></a></li> 3815 <li><em>ISO-8859-1</em> <a href="#rfc.xref.ISO-8859-1.1">3.2 </a>, <a href="#ISO-8859-1"><b>13.1</b></a></li>3833 <li><em>ISO-8859-1</em> <a href="#rfc.xref.ISO-8859-1.1">3.2.1</a>, <a href="#ISO-8859-1"><b>13.1</b></a></li> 3816 3834 </ul> 3817 3835 </li> … … 3892 3910 </ul> 3893 3911 </li> 3894 <li><em>RFC2047</em> <a href="#rfc.xref.RFC2047.1">3.2 </a>, <a href="#RFC2047"><b>13.2</b></a></li>3912 <li><em>RFC2047</em> <a href="#rfc.xref.RFC2047.1">3.2.1</a>, <a href="#RFC2047"><b>13.2</b></a></li> 3895 3913 <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">§</a>, <a href="#rfc.xref.RFC2068.2">2.6</a>, <a href="#rfc.xref.RFC2068.3">7.1.3</a>, <a href="#rfc.xref.RFC2068.4">7.2.3</a>, <a href="#rfc.xref.RFC2068.5">13.1</a>, <a href="#rfc.xref.RFC2068.6">13.1</a>, <a href="#rfc.xref.RFC2068.7">13.1</a>, <a href="#RFC2068"><b>13.2</b></a>, <a href="#rfc.xref.RFC2068.8">A.1.2</a><ul> 3896 3914 <li><em>Section 19.7.1</em> <a href="#rfc.xref.RFC2068.3">7.1.3</a>, <a href="#rfc.xref.RFC2068.8">A.1.2</a></li> … … 3974 3992 </ul> 3975 3993 </li> 3976 <li><em>USASCII</em> <a href="#rfc.xref.USASCII.1">1.2</a>, <a href="#rfc.xref.USASCII.2">3.2 </a>, <a href="#USASCII"><b>13.1</b></a></li>3994 <li><em>USASCII</em> <a href="#rfc.xref.USASCII.1">1.2</a>, <a href="#rfc.xref.USASCII.2">3.2.1</a>, <a href="#USASCII"><b>13.1</b></a></li> 3977 3995 <li>user agent <a href="#rfc.iref.u.1"><b>2.1</b></a></li> 3978 3996 </ul> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1392 r1393 473 473 ; see <xref target="header.fields"/> 474 474 </artwork></figure> 475 <t anchor="rule.token.separators"> 476 <x:anchor-alias value="tchar"/> 477 <x:anchor-alias value="token"/> 478 <x:anchor-alias value="special"/> 479 <x:anchor-alias value="word"/> 480 Many HTTP/1.1 header field values consist of words (token or quoted-string) 481 separated by whitespace or special characters. These special characters 482 &MUST; be in a quoted string to be used within a parameter value (as defined 483 in <xref target="transfer.codings"/>). 484 </t> 485 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="word"/><iref primary="true" item="Grammar" subitem="token"/><iref primary="true" item="Grammar" subitem="tchar"/><iref primary="true" item="Grammar" subitem="special"/> 486 <x:ref>word</x:ref> = <x:ref>token</x:ref> / <x:ref>quoted-string</x:ref> 487 488 <x:ref>token</x:ref> = 1*<x:ref>tchar</x:ref> 489 <!-- 490 IMPORTANT: when editing "tchar" make sure that "special" is updated accordingly!!! 491 --> 492 <x:ref>tchar</x:ref> = "!" / "#" / "$" / "%" / "&" / "'" / "*" 493 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" 494 / <x:ref>DIGIT</x:ref> / <x:ref>ALPHA</x:ref> 495 ; any <x:ref>VCHAR</x:ref>, except <x:ref>special</x:ref> 496 497 <x:ref>special</x:ref> = "(" / ")" / "<" / ">" / "@" / "," 498 / ";" / ":" / "\" / DQUOTE / "/" / "[" 499 / "]" / "?" / "=" / "{" / "}" 500 </artwork></figure> 501 <t anchor="rule.quoted-string"> 502 <x:anchor-alias value="quoted-string"/> 503 <x:anchor-alias value="qdtext"/> 504 <x:anchor-alias value="obs-text"/> 505 A string of text is parsed as a single word if it is quoted using 506 double-quote marks. 507 </t> 508 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="quoted-string"/><iref primary="true" item="Grammar" subitem="qdtext"/><iref primary="true" item="Grammar" subitem="obs-text"/> 509 <x:ref>quoted-string</x:ref> = <x:ref>DQUOTE</x:ref> *( <x:ref>qdtext</x:ref> / <x:ref>quoted-pair</x:ref> ) <x:ref>DQUOTE</x:ref> 510 <x:ref>qdtext</x:ref> = <x:ref>OWS</x:ref> / %x21 / %x23-5B / %x5D-7E / <x:ref>obs-text</x:ref> 511 ; <x:ref>OWS</x:ref> / <<x:ref>VCHAR</x:ref> except <x:ref>DQUOTE</x:ref> and "\"> / <x:ref>obs-text</x:ref> 512 <x:ref>obs-text</x:ref> = %x80-FF 513 </artwork></figure> 514 <t anchor="rule.quoted-pair"> 515 <x:anchor-alias value="quoted-pair"/> 516 The backslash octet ("\") can be used as a single-octet 517 quoting mechanism within quoted-string constructs: 518 </t> 519 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="quoted-pair"/> 520 <x:ref>quoted-pair</x:ref> = "\" ( <x:ref>WSP</x:ref> / <x:ref>VCHAR</x:ref> / <x:ref>obs-text</x:ref> ) 521 </artwork></figure> 522 <t> 523 Recipients that process the value of the quoted-string &MUST; handle a 524 quoted-pair as if it were replaced by the octet following the backslash. 525 </t> 526 <t> 527 Senders &SHOULD-NOT; escape octets that do not require escaping 528 (i.e., other than DQUOTE and the backslash octet). 529 </t> 530 </section> 531 475 </section> 532 476 </section> 533 477 </section> … … 1220 1164 </t> 1221 1165 1222 <section title="Message Parsing Robustness" anchor="message.robustness"> 1166 <section title="Message Parsing and Robustness" anchor="message.robustness"> 1167 <t> 1168 The normal procedure for parsing an HTTP message is to read the 1169 start-line into a structure, read each header field into a hash 1170 table by field name until the empty line, and then use the parsed 1171 data to determine if a message-body is expected. If a message-body 1172 has been indicated, then it is read as a stream until an amount 1173 of octets equal to the message-body length is read or the connection 1174 is closed. 1175 </t> 1176 <t> 1177 Care must be taken to parse an HTTP message as a sequence 1178 of octets in an encoding that is a superset of US-ASCII. Attempting 1179 to parse HTTP as a stream of Unicode characters in a character encoding 1180 like UTF-16 might introduce security flaws due to the differing ways 1181 that such parsers interpret invalid characters. 1182 </t> 1183 <t> 1184 Older HTTP/1.0 client implementations might send an extra CRLF 1185 after a POST request as a lame workaround for some early server 1186 applications that failed to read message-body content that was 1187 not terminated by a line-ending. An HTTP/1.1 client &MUST-NOT; 1188 preface or follow a request with an extra CRLF. If terminating 1189 the request message-body with a line-ending is desired, then the 1190 client &MUST; include the terminating CRLF octets as part of the 1191 message-body length. 1192 </t> 1223 1193 <t> 1224 1194 In the interest of robustness, servers &SHOULD; ignore at least one … … 1231 1201 </t> 1232 1202 <t> 1233 Some old HTTP/1.0 client implementations send an extra CRLF1234 after a POST request as a lame workaround for some early server1235 applications that failed to read message-body content that was1236 not terminated by a line-ending. An HTTP/1.1 client &MUST-NOT;1237 preface or follow a request with an extra CRLF. If terminating1238 the request message-body with a line-ending is desired, then the1239 client &MUST; include the terminating CRLF octets as part of the1240 message-body length.1241 </t>1242 <t>1243 1203 When a server listening only for HTTP request messages, or processing 1244 1204 what appears from the start-line to be an HTTP request message, … … 1246 1206 grammar aside from the robustness exceptions listed above, the 1247 1207 server &MUST; respond with an HTTP/1.1 400 (Bad Request) response. 1248 </t>1249 <t>1250 The normal procedure for parsing an HTTP message is to read the1251 start-line into a structure, read each header field into a hash1252 table by field name until the empty line, and then use the parsed1253 data to determine if a message-body is expected. If a message-body1254 has been indicated, then it is read as a stream until an amount1255 of octets equal to the message-body length is read or the connection1256 is closed. Care must be taken to parse an HTTP message as a sequence1257 of octets in an encoding that is a superset of US-ASCII. Attempting1258 to parse HTTP as a stream of Unicode characters in a character encoding1259 like UTF-16 might introduce security flaws due to the differing ways1260 that such parsers interpret invalid characters.1261 </t>1262 <t>1263 HTTP allows the set of defined header fields to be extended without1264 changing the protocol version (see <xref target="header.field.registration"/>).1265 Unrecognized header fields &MUST; be forwarded by a proxy unless the1266 proxy is specifically configured to block or otherwise transform such1267 fields. Unrecognized header fields &SHOULD; be ignored by other recipients.1268 1208 </t> 1269 1209 </section> … … 1286 1226 </artwork></figure> 1287 1227 <t> 1288 No whitespace is allowed between the header field name and colon. For 1289 security reasons, any request message received containing such whitespace 1290 &MUST; be rejected with a response code of 400 (Bad Request). A proxy 1291 &MUST; remove any such whitespace from a response message before 1292 forwarding the message downstream. 1293 </t> 1294 <t> 1295 A field value &MAY; be preceded by optional whitespace (OWS); a single SP is 1296 preferred. The field value does not include any leading or trailing white 1297 space: OWS occurring before the first non-whitespace octet of the 1298 field value or after the last non-whitespace octet of the field value 1299 is ignored and &SHOULD; be removed before further processing (as this does 1300 not change the meaning of the header field). 1228 The field-name token labels the corresponding field-value as having the 1229 semantics defined by that header field. For example, the Date header field 1230 is defined in <xref target="header.date"/> as containing the origination 1231 timestamp for the message in which it appears. 1232 </t> 1233 <t> 1234 HTTP header fields are fully extensible: there is no limit on the 1235 introduction of new field names, each presumably defining new semantics, 1236 or on the number of header fields used in a given message. Existing 1237 fields are defined in each part of this specification and in many other 1238 specifications outside the standards process. 1239 New header fields can be introduced without changing the protocol version 1240 if their defined semantics allow them to be safely ignored by recipients 1241 that do not recognize them. 1242 </t> 1243 <t> 1244 New HTTP header fields &SHOULD; be registered with IANA according 1245 to the procedures in <xref target="header.field.registration"/>. 1246 Unrecognized header fields &MUST; be forwarded by a proxy unless the 1247 field-name is listed in the Connection header field 1248 (<xref target="header.connection"/>) or the proxy is specifically 1249 configured to block or otherwise transform such fields. 1250 Unrecognized header fields &SHOULD; be ignored by other recipients. 1301 1251 </t> 1302 1252 <t> … … 1333 1283 </t> 1334 1284 </x:note> 1285 1286 <section title="Field Parsing" anchor="field.parsing"> 1287 <t> 1288 No whitespace is allowed between the header field-name and colon. 1289 In the past, differences in the handling of such whitespace have led to 1290 security vulnerabilities in request routing and response handling. 1291 Any received request message that contains whitespace between a header 1292 field-name and colon &MUST; be rejected with a response code of 400 1293 (Bad Request). A proxy &MUST; remove any such whitespace from a response 1294 message before forwarding the message downstream. 1295 </t> 1296 <t> 1297 A field value &MAY; be preceded by optional whitespace (OWS); a single SP is 1298 preferred. The field value does not include any leading or trailing white 1299 space: OWS occurring before the first non-whitespace octet of the 1300 field value or after the last non-whitespace octet of the field value 1301 is ignored and &SHOULD; be removed before further processing (as this does 1302 not change the meaning of the header field). 1303 </t> 1335 1304 <t> 1336 1305 Historically, HTTP header field values could be extended over multiple … … 1339 1308 folding except within the message/http media type 1340 1309 (<xref target="internet.media.type.message.http"/>). 1341 HTTP /1.1senders &MUST-NOT; produce messages that include line folding1310 HTTP senders &MUST-NOT; produce messages that include line folding 1342 1311 (i.e., that contain any field-content that matches the obs-fold rule) unless 1343 1312 the message is intended for packaging within the message/http media type. 1344 HTTP/1.1 recipients &SHOULD; accept line folding and replace any embedded 1345 obs-fold whitespace with a single SP prior to interpreting the field value 1346 or forwarding the message downstream. 1313 HTTP recipients &SHOULD; accept line folding and replace any embedded 1314 obs-fold whitespace with either a single SP or a matching number of SP 1315 octets (to avoid buffer copying) prior to interpreting the field value or 1316 forwarding the message downstream. 1347 1317 </t> 1348 1318 <t> … … 1356 1326 opaque data. 1357 1327 </t> 1328 </section> 1329 1330 <section title="Field Length" anchor="field.length"> 1331 <t> 1332 HTTP does not place a pre-defined limit on the length of header fields, 1333 either in isolation or as a set. A server &MUST; be prepared to receive 1334 request header fields of unbounded length and respond with a 4xx status 1335 code if the received header field(s) would be longer than the server wishes 1336 to handle. 1337 </t> 1338 <t> 1339 A client that receives response headers that are longer than it wishes to 1340 handle can only treat it as a server error. 1341 </t> 1342 <t> 1343 Various ad-hoc limitations on header length are found in practice. It is 1344 &RECOMMENDED; that all HTTP senders and recipients support messages whose 1345 combined header fields have 4000 or more octets. 1346 </t> 1347 </section> 1348 1349 <section title="Common Field ABNF Rules" anchor="field.rules"> 1350 <t anchor="rule.token.separators"> 1351 <x:anchor-alias value="tchar"/> 1352 <x:anchor-alias value="token"/> 1353 <x:anchor-alias value="special"/> 1354 <x:anchor-alias value="word"/> 1355 Many HTTP/1.1 header field values consist of words (token or quoted-string) 1356 separated by whitespace or special characters. These special characters 1357 &MUST; be in a quoted string to be used within a parameter value (as defined 1358 in <xref target="transfer.codings"/>). 1359 </t> 1360 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="word"/><iref primary="true" item="Grammar" subitem="token"/><iref primary="true" item="Grammar" subitem="tchar"/><iref primary="true" item="Grammar" subitem="special"/> 1361 <x:ref>word</x:ref> = <x:ref>token</x:ref> / <x:ref>quoted-string</x:ref> 1362 1363 <x:ref>token</x:ref> = 1*<x:ref>tchar</x:ref> 1364 <!-- 1365 IMPORTANT: when editing "tchar" make sure that "special" is updated accordingly!!! 1366 --> 1367 <x:ref>tchar</x:ref> = "!" / "#" / "$" / "%" / "&" / "'" / "*" 1368 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" 1369 / <x:ref>DIGIT</x:ref> / <x:ref>ALPHA</x:ref> 1370 ; any <x:ref>VCHAR</x:ref>, except <x:ref>special</x:ref> 1371 1372 <x:ref>special</x:ref> = "(" / ")" / "<" / ">" / "@" / "," 1373 / ";" / ":" / "\" / DQUOTE / "/" / "[" 1374 / "]" / "?" / "=" / "{" / "}" 1375 </artwork></figure> 1376 <t anchor="rule.quoted-string"> 1377 <x:anchor-alias value="quoted-string"/> 1378 <x:anchor-alias value="qdtext"/> 1379 <x:anchor-alias value="obs-text"/> 1380 A string of text is parsed as a single word if it is quoted using 1381 double-quote marks. 1382 </t> 1383 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="quoted-string"/><iref primary="true" item="Grammar" subitem="qdtext"/><iref primary="true" item="Grammar" subitem="obs-text"/> 1384 <x:ref>quoted-string</x:ref> = <x:ref>DQUOTE</x:ref> *( <x:ref>qdtext</x:ref> / <x:ref>quoted-pair</x:ref> ) <x:ref>DQUOTE</x:ref> 1385 <x:ref>qdtext</x:ref> = <x:ref>OWS</x:ref> / %x21 / %x23-5B / %x5D-7E / <x:ref>obs-text</x:ref> 1386 <x:ref>obs-text</x:ref> = %x80-FF 1387 </artwork></figure> 1388 <t anchor="rule.quoted-pair"> 1389 <x:anchor-alias value="quoted-pair"/> 1390 The backslash octet ("\") can be used as a single-octet 1391 quoting mechanism within quoted-string constructs: 1392 </t> 1393 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="quoted-pair"/> 1394 <x:ref>quoted-pair</x:ref> = "\" ( <x:ref>WSP</x:ref> / <x:ref>VCHAR</x:ref> / <x:ref>obs-text</x:ref> ) 1395 </artwork></figure> 1396 <t> 1397 Recipients that process the value of the quoted-string &MUST; handle a 1398 quoted-pair as if it were replaced by the octet following the backslash. 1399 </t> 1400 <t> 1401 Senders &SHOULD-NOT; escape octets in quoted-strings that do not require 1402 escaping (i.e., other than DQUOTE and the backslash octet). 1403 </t> 1358 1404 <t anchor="rule.comment"> 1359 1405 <x:anchor-alias value="comment"/> … … 1366 1412 <x:ref>comment</x:ref> = "(" *( <x:ref>ctext</x:ref> / <x:ref>quoted-cpair</x:ref> / <x:ref>comment</x:ref> ) ")" 1367 1413 <x:ref>ctext</x:ref> = <x:ref>OWS</x:ref> / %x21-27 / %x2A-5B / %x5D-7E / <x:ref>obs-text</x:ref> 1368 ; <x:ref>OWS</x:ref> / <<x:ref>VCHAR</x:ref> except "(", ")", and "\"> / <x:ref>obs-text</x:ref>1369 1414 </artwork></figure> 1370 1415 <t anchor="rule.quoted-cpair"> … … 1377 1422 </artwork></figure> 1378 1423 <t> 1379 Senders &SHOULD-NOT; escape octets that do not require escaping 1380 (i.e., other than the backslash octet "\" and the parentheses "(" and 1381 ")"). 1382 </t> 1383 <t> 1384 HTTP does not place a pre-defined limit on the length of header fields, 1385 either in isolation or as a set. A server &MUST; be prepared to receive 1386 request header fields of unbounded length and respond with a 4xx status 1387 code if the received header field(s) would be longer than the server wishes 1388 to handle. 1389 </t> 1390 <t> 1391 A client that receives response headers that are longer than it wishes to 1392 handle can only treat it as a server error. 1393 </t> 1394 <t> 1395 Various ad-hoc limitations on header length are found in practice. It is 1396 &RECOMMENDED; that all HTTP senders and recipients support messages whose 1397 combined header fields have 4000 or more octets. 1398 </t> 1424 Senders &SHOULD-NOT; escape octets in comments that do not require escaping 1425 (i.e., other than the backslash octet "\" and the parentheses "(" and ")"). 1426 </t> 1427 </section> 1399 1428 </section> 1400 1429
Note: See TracChangeset
for help on using the changeset viewer.
