Changeset 647
- Timestamp:
- 28/07/09 15:02:09 (12 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 8 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r636 r647 548 548 </li> 549 549 <li class="tocline0">3. <a href="#http.message">HTTP Message</a><ul class="toc"> 550 <li class="tocline1">3.1 <a href="#message. types">Message Types</a></li>551 <li class="tocline1">3.2 <a href="# message.headers">Message Headers</a></li>550 <li class="tocline1">3.1 <a href="#message.robustness">Message Parsing Robustness</a></li> 551 <li class="tocline1">3.2 <a href="#header.fields">Header Fields</a></li> 552 552 <li class="tocline1">3.3 <a href="#message.body">Message Body</a></li> 553 553 <li class="tocline1">3.4 <a href="#message.length">Message Length</a></li> … … 602 602 </ul> 603 603 </li> 604 <li class="tocline0">8. <a href="#header.field s">Header Field Definitions</a><ul class="toc">604 <li class="tocline0">8. <a href="#header.field.definitions">Header Field Definitions</a><ul class="toc"> 605 605 <li class="tocline1">8.1 <a href="#header.connection">Connection</a></li> 606 606 <li class="tocline1">8.2 <a href="#header.content-length">Content-Length</a></li> … … 769 769 ; "bad" whitespace 770 770 <a href="#rule.whitespace" class="smpl">obs-fold</a> = <a href="#core.rules" class="smpl">CRLF</a> 771 ; see <a href="# message.headers" title="Message Headers">Section 3.2</a>771 ; see <a href="#header.fields" title="Header Fields">Section 3.2</a> 772 772 </pre><div id="rule.token.separators"> 773 773 <p id="rfc.section.1.2.2.p.8"> Many HTTP/1.1 header field values consist of words separated by whitespace or special characters. 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>). … … 911 911 Even when a response is cacheable, there may be additional constraints placed by the client or by the origin server on when 912 912 that cached response can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are 913 defined in <a href="p6-cache.html#caching " title="Introduction">Section 1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.913 defined in <a href="p6-cache.html#caching.overview" title="Cache Operation">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 914 914 </p> 915 915 <p id="rfc.section.2.3.p.5">There are a wide variety of architectures and configurations of caches and proxies deployed across the World Wide Web and 916 916 inside large organizations. These systems include national hierarchies of proxy caches to save transoceanic bandwidth, systems 917 that broadcast or multicast cache entries, organizations that distribute subsets of cached data via CD-ROM, and so on. 917 that broadcast or multicast cache entries, organizations that distribute subsets of cached data via optical media, and so 918 on. 918 919 </p> 919 920 <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> <a id="transport-independence" href="#transport-independence">Transport Independence</a></h2> … … 1063 1064 </p> 1064 1065 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="http.message" href="#http.message">HTTP Message</a></h1> 1065 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="message.types" href="#message.types">Message Types</a></h2> 1066 <p id="rfc.section.3.1.p.1">HTTP messages consist of requests from client to server and responses from server to client.</p> 1067 <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.35"></span> <a href="#message.types" class="smpl">HTTP-message</a> = <a href="#request" class="smpl">Request</a> / <a href="#response" class="smpl">Response</a> ; HTTP/1.1 messages 1068 </pre><p id="rfc.section.3.1.p.3">Request (<a href="#request" title="Request">Section 4</a>) and Response (<a href="#response" title="Response">Section 5</a>) messages use the generic message format of <a href="#RFC5322" id="rfc.xref.RFC5322.2"><cite title="Internet Message Format">[RFC5322]</cite></a> for transferring entities (the payload of the message). Both types of message consist of a start-line, zero or more header 1069 fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header 1070 fields, and possibly a message-body. 1071 </p> 1072 <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.36"></span><span id="rfc.iref.g.37"></span> <a href="#message.types" class="smpl">generic-message</a> = <a href="#message.types" class="smpl">start-line</a> 1073 *( <a href="#message.headers" class="smpl">message-header</a> <a href="#core.rules" class="smpl">CRLF</a> ) 1066 <div id="rfc.iref.h.3"></div> 1067 <div id="rfc.iref.h.4"></div> 1068 <div id="rfc.iref.h.5"></div> 1069 <p id="rfc.section.3.p.1">All HTTP/1.1 messages consist of a start-line followed by a sequence of characters in a format similar to the Internet Message 1070 Format <a href="#RFC5322" id="rfc.xref.RFC5322.2"><cite title="Internet Message Format">[RFC5322]</cite></a>: zero or more header fields (collectively referred to as the "headers" or the "header section"), an empty line indicating 1071 the end of the header section, and an optional message-body. 1072 </p> 1073 <p id="rfc.section.3.p.2">An HTTP message can either be a request from client to server or a response from server to client. Syntactically, the two 1074 types of message differ only in the start-line, which is either a Request-Line (for requests) or a Status-Line (for responses), 1075 and in the algorithm for determining the length of the message-body (<a href="#message.length" title="Message Length">Section 3.4</a>). In theory, a client could receive requests and a server could receive responses, distinguishing them by their different 1076 start-line formats, but in practice servers are implemented to only expect a request (a response is interpreted as an unknown 1077 or invalid request method) and clients are implemented to only expect a response. 1078 </p> 1079 <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.35"></span> <a href="#http.message" class="smpl">HTTP-message</a> = <a href="#http.message" class="smpl">start-line</a> 1080 *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> ) 1074 1081 <a href="#core.rules" class="smpl">CRLF</a> 1075 1082 [ <a href="#message.body" class="smpl">message-body</a> ] 1076 <a href="#message.types" class="smpl">start-line</a> = <a href="#request-line" class="smpl">Request-Line</a> / <a href="#status-line" class="smpl">Status-Line</a> 1077 </pre><p id="rfc.section.3.1.p.5">In the interest of robustness, servers <em class="bcp14">SHOULD</em> ignore any empty line(s) received where a Request-Line is expected. In other words, if the server is reading the protocol 1078 stream at the beginning of a message and receives a CRLF first, it should ignore the CRLF. 1079 </p> 1080 <p id="rfc.section.3.1.p.6">Certain buggy HTTP/1.0 client implementations generate extra CRLF's after a POST request. To restate what is explicitly forbidden 1081 by the BNF, an HTTP/1.1 client <em class="bcp14">MUST NOT</em> preface or follow a request with an extra CRLF. 1082 </p> 1083 <p id="rfc.section.3.1.p.7">Whitespace (WSP) <em class="bcp14">MUST NOT</em> be sent between the start-line and the first header field. The presence of whitespace might be an attempt to trick a noncompliant 1083 <a href="#http.message" class="smpl">start-line</a> = <a href="#request-line" class="smpl">Request-Line</a> / <a href="#status-line" class="smpl">Status-Line</a> 1084 </pre><p id="rfc.section.3.p.4">Whitespace (WSP) <em class="bcp14">MUST NOT</em> be sent between the start-line and the first header field. The presence of whitespace might be an attempt to trick a noncompliant 1084 1085 implementation of HTTP into ignoring that field or processing the next line as a new request, either of which may result in 1085 1086 security issues when implementations within the request chain interpret the same message differently. HTTP/1.1 servers <em class="bcp14">MUST</em> reject such a message with a 400 (Bad Request) response. 1086 1087 </p> 1087 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="message.headers" href="#message.headers">Message Headers</a></h2> 1088 <p id="rfc.section.3.2.p.1">HTTP header fields follow the same general format as Internet messages in <a href="http://tools.ietf.org/html/rfc5322#section-2.1">Section 2.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>. Each header field consists of a name followed by a colon (":"), optional whitespace, and the field value. Field names are 1089 case-insensitive. 1090 </p> 1091 <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span> <a href="#message.headers" class="smpl">message-header</a> = <a href="#message.headers" class="smpl">field-name</a> ":" OWS [ <a href="#message.headers" class="smpl">field-value</a> ] OWS 1092 <a href="#message.headers" class="smpl">field-name</a> = <a href="#rule.token.separators" class="smpl">token</a> 1093 <a href="#message.headers" class="smpl">field-value</a> = *( <a href="#message.headers" class="smpl">field-content</a> / <a href="#rule.whitespace" class="smpl">OWS</a> ) 1094 <a href="#message.headers" 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> ) 1095 </pre><p id="rfc.section.3.2.p.3">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 (allowing other character sets 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 charset <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> constrain their field-values to US-ASCII characters. Recipients <em class="bcp14">SHOULD</em> treat other (obs-text) octets in field-content as opaque data. 1096 </p> 1097 <p id="rfc.section.3.2.p.4">No whitespace is allowed between the header field-name and colon. For security reasons, any request message received containing 1098 such whitespace <em class="bcp14">MUST</em> be rejected with a response code of 400 (Bad Request) and any such whitespace in a response message <em class="bcp14">MUST</em> be removed. 1099 </p> 1100 <p id="rfc.section.3.2.p.5">The field value <em class="bcp14">MAY</em> be preceded by optional whitespace; a single SP is preferred. The field-value does not include any leading or trailing white 1101 space: OWS occurring before the first non-whitespace character of the field-value or after the last non-whitespace character 1102 of the field-value is ignored and <em class="bcp14">MAY</em> be removed without changing the meaning of the header field. 1103 </p> 1104 <p id="rfc.section.3.2.p.6">Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one 1105 space or horizontal tab character (line folding). This specification deprecates such line folding except within the message/http 1106 media type (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section 9.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 1107 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 1108 forwarding the message downstream. 1109 </p> 1110 <div id="rule.comment"> 1111 <p id="rfc.section.3.2.p.7"> Comments can be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed 1112 in fields containing "comment" as part of their field value definition. In all other fields, parentheses are considered part 1113 of the field value. 1114 </p> 1115 </div> 1116 <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span> <a href="#rule.comment" class="smpl">comment</a> = "(" *( <a href="#rule.comment" class="smpl">ctext</a> / <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> / <a href="#rule.comment" class="smpl">comment</a> ) ")" 1117 <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> 1118 ; <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> 1119 </pre><p id="rfc.section.3.2.p.9">The order in which header fields with differing field names are received is not significant. However, it is "good practice" 1120 to send general-header fields first, followed by request-header or response-header fields, and ending with the entity-header 1121 fields. 1122 </p> 1123 <p id="rfc.section.3.2.p.10">Multiple message-header fields with the same field-name <em class="bcp14">MAY</em> be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., 1124 #(values)]. It <em class="bcp14">MUST</em> be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics 1125 of the message, by appending each subsequent field-value to the first, each separated by a comma. The order in which header 1126 fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and 1127 thus a proxy <em class="bcp14">MUST NOT</em> change the order of these field values when a message is forwarded. 1088 <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> 1089 <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 1090 stream at the beginning of a message and receives a CRLF first, it should ignore the CRLF. 1091 </p> 1092 <p id="rfc.section.3.1.p.2">Some old HTTP/1.0 client implementations generate an extra CRLF after a POST request as a lame workaround for some early server 1093 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 1094 the client <em class="bcp14">MUST</em> include the terminating CRLF octets as part of the message-body length. 1095 </p> 1096 <p id="rfc.section.3.1.p.3">The normal procedure for parsing an HTTP message is to read the start-line into a structure, read each header field into a 1097 hash table by field name until the empty line, and then use the parsed data to determine if a message-body is expected. If 1098 a message-body has been indicated, then it is read as a stream until an amount of OCTETs equal to the message-length is read 1099 or the connection is closed. Care must be taken to parse an HTTP message as a sequence of OCTETs in an encoding that is a 1100 superset of US-ASCII. Attempting to parse HTTP as a stream of Unicode characters in a character encoding like UTF-16 may introduce 1101 security flaws due to the differing ways that such parsers interpret invalid characters. 1102 </p> 1103 <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> 1104 <p id="rfc.section.3.2.p.1">Each HTTP header field consists of a case-insensitive field name followed by a colon (":"), optional whitespace, and the field 1105 value. 1106 </p> 1107 <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.36"></span><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span> <a href="#header.fields" class="smpl">header-field</a> = <a href="#header.fields" class="smpl">field-name</a> ":" OWS [ <a href="#header.fields" class="smpl">field-value</a> ] OWS 1108 <a href="#header.fields" class="smpl">field-name</a> = <a href="#rule.token.separators" class="smpl">token</a> 1109 <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> ) 1110 <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> ) 1111 </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 1112 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. 1113 </p> 1114 <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 1115 white space: OWS occurring before the first non-whitespace character of the field value or after the last non-whitespace character 1116 of the field value is ignored and <em class="bcp14">SHOULD</em> be removed without changing the meaning of the header field. 1117 </p> 1118 <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" 1119 to send header fields that contain control data first, such as Host on requests and Date on responses, so that implementations 1120 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 1121 conditionals, authentication credentials, or deliberately misleading duplicate header fields that would impact request processing. 1122 </p> 1123 <p id="rfc.section.3.2.p.6">Multiple header fields with the same field name <em class="bcp14">MAY</em> be sent in a message if and only if the entire field value for that header field is defined as a comma-separated list [i.e., 1124 #(values)]. Multiple header fields with the same field name can be combined into one "field-name: field-value" pair, without 1125 changing the semantics of the message, by appending each subsequent field value to the combined field value in order, separated 1126 by a comma. The order in which header fields with the same field name are received is therefore significant to the interpretation 1127 of the combined field value; a proxy <em class="bcp14">MUST NOT</em> change the order of these field values when forwarding a message. 1128 1128 </p> 1129 1129 <div class="note"> … … 1132 1132 </p> 1133 1133 </div> 1134 <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> 1134 <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 1135 space or horizontal tab character (line folding). This specification deprecates such line folding except within the message/http 1136 media type (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section 9.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 1137 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 1138 forwarding the message downstream. 1139 </p> 1140 <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 characters. Recipients <em class="bcp14">SHOULD</em> treat other (obs-text) octets in field content as opaque data. 1141 </p> 1142 <div id="rule.comment"> 1143 <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 allowed 1144 in fields containing "comment" as part of their field value definition. 1145 </p> 1146 </div> 1147 <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span> <a href="#rule.comment" class="smpl">comment</a> = "(" *( <a href="#rule.comment" class="smpl">ctext</a> / <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> / <a href="#rule.comment" class="smpl">comment</a> ) ")" 1148 <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> 1149 ; <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> 1150 </pre><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> 1135 1151 <p id="rfc.section.3.3.p.1">The message-body (if any) of an HTTP message is used to carry the entity-body associated with the request or response. The 1136 1152 message-body differs from the entity-body only when a transfer-coding has been applied, as indicated by the Transfer-Encoding 1137 1153 header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section 8.7</a>). 1138 1154 </p> 1139 <div id="rfc.figure.u.2 6"></div><pre class="inline"><span id="rfc.iref.g.44"></span> <a href="#message.body" class="smpl">message-body</a> = <a href="#abnf.dependencies" class="smpl">entity-body</a>1155 <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.42"></span> <a href="#message.body" class="smpl">message-body</a> = <a href="#abnf.dependencies" class="smpl">entity-body</a> 1140 1156 / <entity-body encoded as per <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>> 1141 1157 </pre><p id="rfc.section.3.3.p.3">Transfer-Encoding <em class="bcp14">MUST</em> be used to indicate any transfer-codings applied by an application to ensure safe and proper transfer of the message. Transfer-Encoding … … 1144 1160 <p id="rfc.section.3.3.p.4">The rules for when a message-body is allowed in a message differ for requests and responses.</p> 1145 1161 <p id="rfc.section.3.3.p.5">The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field 1146 in the request's message-headers. When a request message contains both a message-body of non-zero length and a method that1147 doesnot define any semantics for that request message-body, then an origin server <em class="bcp14">SHOULD</em> either ignore the message-body or respond with an appropriate error message (e.g., 413). A proxy or gateway, when presented1162 in the request's header fields. When a request message contains both a message-body of non-zero length and a method that does 1163 not define any semantics for that request message-body, then an origin server <em class="bcp14">SHOULD</em> either ignore the message-body or respond with an appropriate error message (e.g., 413). A proxy or gateway, when presented 1148 1164 the same request, <em class="bcp14">SHOULD</em> either forward the request inbound with the message-body or ignore the message-body when determining a response. 1149 1165 </p> … … 1204 1220 to the entity being transferred. These header fields apply only to the message being transmitted. 1205 1221 </p> 1206 <div id="rfc.figure.u.2 7"></div><pre class="inline"><span id="rfc.iref.g.45"></span> <a href="#general.header.fields" class="smpl">general-header</a> = <a href="#abnf.dependencies" class="smpl">Cache-Control</a> ; <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a>1222 <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.43"></span> <a href="#general.header.fields" class="smpl">general-header</a> = <a href="#abnf.dependencies" class="smpl">Cache-Control</a> ; <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> 1207 1223 / <a href="#header.connection" class="smpl">Connection</a> ; <a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section 8.1</a> 1208 1224 / <a href="#header.date" class="smpl">Date</a> ; <a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section 8.3</a> … … 1221 1237 resource, the identifier of the resource, and the protocol version in use. 1222 1238 </p> 1223 <div id="rfc.figure.u.2 8"></div><pre class="inline"><span id="rfc.iref.g.46"></span> <a href="#request" class="smpl">Request</a> = <a href="#request-line" class="smpl">Request-Line</a> ; <a href="#request-line" title="Request-Line">Section 4.1</a>1239 <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.44"></span> <a href="#request" class="smpl">Request</a> = <a href="#request-line" class="smpl">Request-Line</a> ; <a href="#request-line" title="Request-Line">Section 4.1</a> 1224 1240 *(( <a href="#general.header.fields" class="smpl">general-header</a> ; <a href="#general.header.fields" title="General Header Fields">Section 3.5</a> 1225 1241 / <a href="#abnf.dependencies" class="smpl">request-header</a> ; <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 3</a> … … 1231 1247 The elements are separated by SP characters. No CR or LF is allowed except in the final CRLF sequence. 1232 1248 </p> 1233 <div id="rfc.figure.u.2 9"></div><pre class="inline"><span id="rfc.iref.g.47"></span> <a href="#request-line" class="smpl">Request-Line</a> = <a href="#method" class="smpl">Method</a> <a href="#core.rules" class="smpl">SP</a> <a href="#request-target" class="smpl">request-target</a> <a href="#core.rules" class="smpl">SP</a> <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">CRLF</a>1249 <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.45"></span> <a href="#request-line" class="smpl">Request-Line</a> = <a href="#method" class="smpl">Method</a> <a href="#core.rules" class="smpl">SP</a> <a href="#request-target" class="smpl">request-target</a> <a href="#core.rules" class="smpl">SP</a> <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">CRLF</a> 1234 1250 </pre><h3 id="rfc.section.4.1.1"><a href="#rfc.section.4.1.1">4.1.1</a> <a id="method" href="#method">Method</a></h3> 1235 1251 <p id="rfc.section.4.1.1.p.1">The Method token indicates the method to be performed on the resource identified by the request-target. The method is case-sensitive.</p> 1236 <div id="rfc.figure.u. 30"></div><pre class="inline"><span id="rfc.iref.g.48"></span><span id="rfc.iref.g.49"></span> <a href="#method" class="smpl">Method</a> = <a href="#rule.token.separators" class="smpl">token</a>1252 <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.46"></span><span id="rfc.iref.g.47"></span> <a href="#method" class="smpl">Method</a> = <a href="#rule.token.separators" class="smpl">token</a> 1237 1253 </pre><h3 id="rfc.section.4.1.2"><a href="#rfc.section.4.1.2">4.1.2</a> <a id="request-target" href="#request-target">request-target</a></h3> 1238 1254 <p id="rfc.section.4.1.2.p.1">The request-target identifies the resource upon which to apply the request.</p> 1239 <div id="rfc.figure.u.3 1"></div><pre class="inline"><span id="rfc.iref.g.50"></span> <a href="#request-target" class="smpl">request-target</a> = "*"1255 <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.48"></span> <a href="#request-target" class="smpl">request-target</a> = "*" 1240 1256 / <a href="#uri" class="smpl">absolute-URI</a> 1241 1257 / ( <a href="#uri" class="smpl">path-absolute</a> [ "?" <a href="#uri" class="smpl">query</a> ] ) … … 1245 1261 apply to a resource. One example would be 1246 1262 </p> 1247 <div id="rfc.figure.u.3 2"></div><pre class="text"> OPTIONS * HTTP/1.11263 <div id="rfc.figure.u.31"></div><pre class="text"> OPTIONS * HTTP/1.1 1248 1264 </pre><p id="rfc.section.4.1.2.p.5">The absolute-URI form is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to forward the request or service it from a valid cache, 1249 1265 and return the response. Note that the proxy <em class="bcp14">MAY</em> forward the request on to another proxy or directly to the server specified by the absolute-URI. In order to avoid request … … 1251 1267 Request-Line would be: 1252 1268 </p> 1253 <div id="rfc.figure.u.3 3"></div><pre class="text"> GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.11269 <div id="rfc.figure.u.32"></div><pre class="text"> GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 1254 1270 </pre><p id="rfc.section.4.1.2.p.7">To allow for transition to absolute-URIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absolute-URI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies. 1255 1271 </p> … … 1260 1276 server would create a TCP connection to port 80 of the host "www.example.org" and send the lines: 1261 1277 </p> 1262 <div id="rfc.figure.u.3 4"></div><pre class="text"> GET /pub/WWW/TheProject.html HTTP/1.11278 <div id="rfc.figure.u.33"></div><pre class="text"> GET /pub/WWW/TheProject.html HTTP/1.1 1263 1279 Host: www.example.org 1264 1280 </pre><p id="rfc.section.4.1.2.p.11">followed by the remainder of the Request. Note that the absolute path cannot be empty; if none is present in the original … … 1268 1284 asterisk form of request-target, then the last proxy on the request chain <em class="bcp14">MUST</em> forward the request with "*" as the final request-target. 1269 1285 </p> 1270 <div id="rfc.figure.u.3 5"></div>1286 <div id="rfc.figure.u.34"></div> 1271 1287 <p>For example, the request</p><pre class="text"> OPTIONS http://www.example.org:8001 HTTP/1.1 1272 </pre><div id="rfc.figure.u.3 6"></div>1288 </pre><div id="rfc.figure.u.35"></div> 1273 1289 <p>would be forwarded by the proxy as</p><pre class="text"> OPTIONS * HTTP/1.1 1274 1290 Host: www.example.org:8001 … … 1313 1329 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="response" href="#response">Response</a></h1> 1314 1330 <p id="rfc.section.5.p.1">After receiving and interpreting a request message, a server responds with an HTTP response message.</p> 1315 <div id="rfc.figure.u.3 7"></div><pre class="inline"><span id="rfc.iref.g.51"></span> <a href="#response" class="smpl">Response</a> = <a href="#status-line" class="smpl">Status-Line</a> ; <a href="#status-line" title="Status-Line">Section 5.1</a>1331 <div id="rfc.figure.u.36"></div><pre class="inline"><span id="rfc.iref.g.49"></span> <a href="#response" class="smpl">Response</a> = <a href="#status-line" class="smpl">Status-Line</a> ; <a href="#status-line" title="Status-Line">Section 5.1</a> 1316 1332 *(( <a href="#general.header.fields" class="smpl">general-header</a> ; <a href="#general.header.fields" title="General Header Fields">Section 3.5</a> 1317 1333 / <a href="#abnf.dependencies" class="smpl">response-header</a> ; <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 5</a> … … 1324 1340 CRLF sequence. 1325 1341 </p> 1326 <div id="rfc.figure.u.3 8"></div><pre class="inline"><span id="rfc.iref.g.52"></span> <a href="#status-line" class="smpl">Status-Line</a> = <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> <a href="#core.rules" class="smpl">CRLF</a>1342 <div id="rfc.figure.u.37"></div><pre class="inline"><span id="rfc.iref.g.50"></span> <a href="#status-line" class="smpl">Status-Line</a> = <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> <a href="#core.rules" class="smpl">CRLF</a> 1327 1343 </pre><h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a> <a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h3> 1328 1344 <p id="rfc.section.5.1.1.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. These codes … … 1341 1357 <li>5xx: Server Error - The server failed to fulfill an apparently valid request</li> 1342 1358 </ul> 1343 <div id="rfc.figure.u.3 9"></div><pre class="inline"><span id="rfc.iref.g.53"></span><span id="rfc.iref.g.54"></span><span id="rfc.iref.g.55"></span> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> = 3<a href="#core.rules" class="smpl">DIGIT</a>1359 <div id="rfc.figure.u.38"></div><pre class="inline"><span id="rfc.iref.g.51"></span><span id="rfc.iref.g.52"></span><span id="rfc.iref.g.53"></span> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> = 3<a href="#core.rules" class="smpl">DIGIT</a> 1344 1360 <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</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> ) 1345 1361 </pre><h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1> 1346 1362 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="date.time.formats.full.date" href="#date.time.formats.full.date">Date/Time Formats: Full Date</a></h2> 1347 1363 <p id="rfc.section.6.1.p.1">HTTP applications have historically allowed three different formats for the representation of date/time stamps:</p> 1348 <div id="rfc.figure.u. 40"></div><pre class="text"> Sun, 06 Nov 1994 08:49:37 GMT ; RFC 11231364 <div id="rfc.figure.u.39"></div><pre class="text"> Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 1349 1365 Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 1350 1366 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format … … 1356 1372 time zone, and <em class="bcp14">MUST</em> be assumed when reading the asctime format. HTTP-date is case sensitive and <em class="bcp14">MUST NOT</em> include additional whitespace beyond that specifically included as SP in the grammar. 1357 1373 </p> 1358 <div id="rfc.figure.u.4 1"></div><pre class="inline"><span id="rfc.iref.g.56"></span> <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a> = <a href="#preferred.date.format" class="smpl">rfc1123-date</a> / <a href="#obsolete.date.formats" class="smpl">obs-date</a>1374 <div id="rfc.figure.u.40"></div><pre class="inline"><span id="rfc.iref.g.54"></span> <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a> = <a href="#preferred.date.format" class="smpl">rfc1123-date</a> / <a href="#obsolete.date.formats" class="smpl">obs-date</a> 1359 1375 </pre><div id="preferred.date.format"> 1360 1376 <p id="rfc.section.6.1.p.6"> Preferred format:</p> 1361 1377 </div> 1362 <div id="rfc.figure.u.4 2"></div><pre class="inline"><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span><span id="rfc.iref.g.66"></span><span id="rfc.iref.g.67"></span><span id="rfc.iref.g.68"></span> <a href="#preferred.date.format" class="smpl">rfc1123-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> "," <a href="#core.rules" class="smpl">SP</a> date1 <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a>1378 <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span><span id="rfc.iref.g.66"></span> <a href="#preferred.date.format" class="smpl">rfc1123-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> "," <a href="#core.rules" class="smpl">SP</a> date1 <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a> 1363 1379 1364 1380 <a href="#preferred.date.format" class="smpl">day-name</a> = %x4D.6F.6E ; "Mon", case-sensitive … … 1396 1412 <a href="#preferred.date.format" class="smpl">minute</a> = 2<a href="#core.rules" class="smpl">DIGIT</a> 1397 1413 <a href="#preferred.date.format" class="smpl">second</a> = 2<a href="#core.rules" class="smpl">DIGIT</a> 1398 </pre><p id="rfc.section.6.1.p.8">The semantics of <a href="#preferred.date.format" class="smpl">day-name</a>, <a href="#preferred.date.format" class="smpl">day</a>, <a href="#preferred.date.format" class="smpl">month</a>, <a href="#preferred.date.format" class="smpl">year</a>, and <a href="#preferred.date.format" class="smpl">time-of-day</a> are the same as those defined for the RFC 5322 constructs with the corresponding name (<a href="#RFC5322" id="rfc.xref.RFC5322. 4"><cite title="Internet Message Format">[RFC5322]</cite></a>, <a href="http://tools.ietf.org/html/rfc5322#section-3.3">Section 3.3</a>).1414 </pre><p id="rfc.section.6.1.p.8">The semantics of <a href="#preferred.date.format" class="smpl">day-name</a>, <a href="#preferred.date.format" class="smpl">day</a>, <a href="#preferred.date.format" class="smpl">month</a>, <a href="#preferred.date.format" class="smpl">year</a>, and <a href="#preferred.date.format" class="smpl">time-of-day</a> are the same as those defined for the RFC 5322 constructs with the corresponding name (<a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>, <a href="http://tools.ietf.org/html/rfc5322#section-3.3">Section 3.3</a>). 1399 1415 </p> 1400 1416 <div id="obsolete.date.formats"> 1401 1417 <p id="rfc.section.6.1.p.9"> Obsolete formats:</p> 1402 1418 </div> 1403 <div id="rfc.figure.u.4 3"></div><pre class="inline"><span id="rfc.iref.g.69"></span> <a href="#obsolete.date.formats" class="smpl">obs-date</a> = <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> / <a href="#obsolete.date.formats" class="smpl">asctime-date</a>1404 </pre><div id="rfc.figure.u.4 4"></div><pre class="inline"><span id="rfc.iref.g.70"></span> <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> = <a href="#obsolete.date.formats" class="smpl">day-name-l</a> "," <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date2</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a>1419 <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.67"></span> <a href="#obsolete.date.formats" class="smpl">obs-date</a> = <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> / <a href="#obsolete.date.formats" class="smpl">asctime-date</a> 1420 </pre><div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.68"></span> <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> = <a href="#obsolete.date.formats" class="smpl">day-name-l</a> "," <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date2</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a> 1405 1421 <a href="#obsolete.date.formats" class="smpl">date2</a> = <a href="#preferred.date.format" class="smpl">day</a> "-" <a href="#preferred.date.format" class="smpl">month</a> "-" 2<a href="#core.rules" class="smpl">DIGIT</a> 1406 1422 ; day-month-year (e.g., 02-Jun-82) … … 1413 1429 / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive 1414 1430 / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive 1415 </pre><div id="rfc.figure.u.4 5"></div><pre class="inline"><span id="rfc.iref.g.71"></span> <a href="#obsolete.date.formats" class="smpl">asctime-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date3</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">year</a>1431 </pre><div id="rfc.figure.u.44"></div><pre class="inline"><span id="rfc.iref.g.69"></span> <a href="#obsolete.date.formats" class="smpl">asctime-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date3</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">year</a> 1416 1432 <a href="#obsolete.date.formats" class="smpl">date3</a> = <a href="#preferred.date.format" class="smpl">month</a> <a href="#core.rules" class="smpl">SP</a> ( 2<a href="#core.rules" class="smpl">DIGIT</a> / ( <a href="#core.rules" class="smpl">SP</a> 1<a href="#core.rules" class="smpl">DIGIT</a> )) 1417 1433 ; month day (e.g., Jun 2) … … 1431 1447 is a property of the message, not of the original entity. 1432 1448 </p> 1433 <div id="rfc.figure.u.4 6"></div><pre class="inline"><span id="rfc.iref.g.72"></span><span id="rfc.iref.g.73"></span> <a href="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" / <a href="#transfer.codings" class="smpl">transfer-extension</a>1449 <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.70"></span><span id="rfc.iref.g.71"></span> <a href="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" / <a href="#transfer.codings" class="smpl">transfer-extension</a> 1434 1450 <a href="#transfer.codings" class="smpl">transfer-extension</a> = <a href="#rule.token.separators" class="smpl">token</a> *( <a href="#rule.whitespace" class="smpl">OWS</a> ";" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">transfer-parameter</a> ) 1435 1451 </pre><div id="rule.parameter"> 1436 1452 <p id="rfc.section.6.2.p.3"> Parameters are in the form of attribute/value pairs.</p> 1437 1453 </div> 1438 <div id="rfc.figure.u.4 7"></div><pre class="inline"><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span><span id="rfc.iref.g.77"></span><span id="rfc.iref.g.78"></span> <a href="#rule.parameter" class="smpl">transfer-parameter</a> = <a href="#rule.parameter" class="smpl">attribute</a> <a href="#rule.whitespace" class="smpl">BWS</a> "=" <a href="#rule.whitespace" class="smpl">BWS</a> <a href="#rule.parameter" class="smpl">value</a>1454 <div id="rfc.figure.u.46"></div><pre class="inline"><span id="rfc.iref.g.72"></span><span id="rfc.iref.g.73"></span><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span> <a href="#rule.parameter" class="smpl">transfer-parameter</a> = <a href="#rule.parameter" class="smpl">attribute</a> <a href="#rule.whitespace" class="smpl">BWS</a> "=" <a href="#rule.whitespace" class="smpl">BWS</a> <a href="#rule.parameter" class="smpl">value</a> 1439 1455 <a href="#rule.parameter" class="smpl">attribute</a> = <a href="#rule.token.separators" class="smpl">token</a> 1440 1456 <a href="#rule.parameter" class="smpl">value</a> = <a href="#rule.token.separators" class="smpl">token</a> / <a href="#rule.quoted-string" class="smpl">quoted-string</a> … … 1445 1461 (<a href="#message.length" title="Message Length">Section 3.4</a>). 1446 1462 </p> 1447 <p id="rfc.section.6.2.p.7">Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME <a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>, which were designed to enable safe transport of binary data over a 7-bit transport service. However, safe transport has1448 a different focus for an 8bit-clean transfer protocol. In HTTP, the only unsafe characteristic of message-bodies is the difficulty1449 in determining the exact body length (<a href="#message.length" title="Message Length">Section 3.4</a>), or the desire to encrypt data over a shared transport.1463 <p id="rfc.section.6.2.p.7">Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME, which were designed to enable safe transport 1464 of binary data over a 7-bit transport service (<a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>, <a href="http://tools.ietf.org/html/rfc2045#section-6">Section 6</a>). However, safe transport has a different focus for an 8bit-clean transfer protocol. In HTTP, the only unsafe characteristic 1465 of message-bodies is the difficulty in determining the exact body length (<a href="#message.length" title="Message Length">Section 3.4</a>), or the desire to encrypt data over a shared transport. 1450 1466 </p> 1451 1467 <p id="rfc.section.6.2.p.8">The Internet Assigned Numbers Authority (IANA) acts as a registry for transfer-coding value tokens. Initially, the registry … … 1461 1477 necessary for the recipient to verify that it has received the full message. 1462 1478 </p> 1463 <div id="rfc.figure.u.4 8"></div><pre class="inline"><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span> <a href="#chunked.transfer.encoding" class="smpl">Chunked-Body</a> = *<a href="#chunked.transfer.encoding" class="smpl">chunk</a>1479 <div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.77"></span><span id="rfc.iref.g.78"></span><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span> <a href="#chunked.transfer.encoding" class="smpl">Chunked-Body</a> = *<a href="#chunked.transfer.encoding" class="smpl">chunk</a> 1464 1480 <a href="#chunked.transfer.encoding" class="smpl">last-chunk</a> 1465 1481 <a href="#chunked.transfer.encoding" class="smpl">trailer-part</a> … … 1499 1515 </p> 1500 1516 <p id="rfc.section.6.2.1.p.7">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p> 1501 <div id="rfc.figure.u.4 9"></div><pre class="text"> length := 01517 <div id="rfc.figure.u.48"></div><pre class="text"> length := 0 1502 1518 read chunk-size, chunk-ext (if any) and CRLF 1503 1519 while (chunk-size > 0) { … … 1521 1537 By convention, the products are listed in order of their significance for identifying the application. 1522 1538 </p> 1523 <div id="rfc.figure.u. 50"></div><pre class="inline"><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span> <a href="#product.tokens" class="smpl">product</a> = <a href="#rule.token.separators" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>]1539 <div id="rfc.figure.u.49"></div><pre class="inline"><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span> <a href="#product.tokens" class="smpl">product</a> = <a href="#rule.token.separators" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>] 1524 1540 <a href="#product.tokens" class="smpl">product-version</a> = <a href="#rule.token.separators" class="smpl">token</a> 1525 1541 </pre><p id="rfc.section.6.3.p.3">Examples:</p> 1526 <div id="rfc.figure.u.5 1"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b31542 <div id="rfc.figure.u.50"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1527 1543 Server: Apache/0.8.4 1528 1544 </pre><p id="rfc.section.6.3.p.5">Product tokens <em class="bcp14">SHOULD</em> be short and to the point. They <em class="bcp14">MUST NOT</em> be used for advertising or other non-essential information. Although any token character <em class="bcp14">MAY</em> appear in a product-version, this token <em class="bcp14">SHOULD</em> only be used for a version identifier (i.e., successive versions of the same product <em class="bcp14">SHOULD</em> only differ in the product-version portion of the product value). … … 1533 1549 a quality value of 0, then content with this parameter is `not acceptable' for the client. HTTP/1.1 applications <em class="bcp14">MUST NOT</em> generate more than three digits after the decimal point. User configuration of these values <em class="bcp14">SHOULD</em> also be limited in this fashion. 1534 1550 </p> 1535 <div id="rfc.figure.u.5 2"></div><pre class="inline"><span id="rfc.iref.g.90"></span> <a href="#quality.values" class="smpl">qvalue</a> = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] )1551 <div id="rfc.figure.u.51"></div><pre class="inline"><span id="rfc.iref.g.88"></span> <a href="#quality.values" class="smpl">qvalue</a> = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] ) 1536 1552 / ( "1" [ "." 0*3("0") ] ) 1537 1553 </pre><div class="note"> … … 1717 1733 </li> 1718 1734 </ul> 1719 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="header.field s" href="#header.fields">Header Field Definitions</a></h1>1735 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1> 1720 1736 <p id="rfc.section.8.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to message framing and transport protocols.</p> 1721 1737 <p id="rfc.section.8.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who … … 1723 1739 </p> 1724 1740 <div id="rfc.iref.c.5"></div> 1725 <div id="rfc.iref.h. 3"></div>1741 <div id="rfc.iref.h.6"></div> 1726 1742 <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a> <a id="header.connection" href="#header.connection">Connection</a></h2> 1727 1743 <p id="rfc.section.8.1.p.1">The general-header field "Connection" allows the sender to specify options that are desired for that particular connection … … 1729 1745 </p> 1730 1746 <p id="rfc.section.8.1.p.2">The Connection header's value has the following grammar:</p> 1731 <div id="rfc.figure.u.5 3"></div><pre class="inline"><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span><span id="rfc.iref.g.93"></span> <a href="#header.connection" class="smpl">Connection</a> = "Connection" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.connection" class="smpl">Connection-v</a>1747 <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></span><span id="rfc.iref.g.91"></span> <a href="#header.connection" class="smpl">Connection</a> = "Connection" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.connection" class="smpl">Connection-v</a> 1732 1748 <a href="#header.connection" class="smpl">Connection-v</a> = 1#<a href="#header.connection" class="smpl">connection-token</a> 1733 1749 <a href="#header.connection" class="smpl">connection-token</a> = <a href="#rule.token.separators" class="smpl">token</a> … … 1742 1758 of the response. For example, 1743 1759 </p> 1744 <div id="rfc.figure.u.5 4"></div><pre class="text"> Connection: close1760 <div id="rfc.figure.u.53"></div><pre class="text"> Connection: close 1745 1761 </pre><p id="rfc.section.8.1.p.8">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD NOT</em> be considered `persistent' (<a href="#persistent.connections" title="Persistent Connections">Section 7.1</a>) after the current request/response is complete. 1746 1762 </p> … … 1753 1769 </p> 1754 1770 <div id="rfc.iref.c.6"></div> 1755 <div id="rfc.iref.h. 4"></div>1771 <div id="rfc.iref.h.7"></div> 1756 1772 <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a> <a id="header.content-length" href="#header.content-length">Content-Length</a></h2> 1757 1773 <p id="rfc.section.8.2.p.1">The entity-header field "Content-Length" indicates the size of the entity-body, in number of OCTETs, sent to the recipient 1758 1774 or, in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET. 1759 1775 </p> 1760 <div id="rfc.figure.u.5 5"></div><pre class="inline"><span id="rfc.iref.g.94"></span><span id="rfc.iref.g.95"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = "Content-Length" ":" <a href="#rule.whitespace" class="smpl">OWS</a> 1*<a href="#header.content-length" class="smpl">Content-Length-v</a>1776 <div id="rfc.figure.u.54"></div><pre class="inline"><span id="rfc.iref.g.92"></span><span id="rfc.iref.g.93"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = "Content-Length" ":" <a href="#rule.whitespace" class="smpl">OWS</a> 1*<a href="#header.content-length" class="smpl">Content-Length-v</a> 1761 1777 <a href="#header.content-length" class="smpl">Content-Length-v</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a> 1762 1778 </pre><p id="rfc.section.8.2.p.3">An example is</p> 1763 <div id="rfc.figure.u.5 6"></div><pre class="text"> Content-Length: 34951779 <div id="rfc.figure.u.55"></div><pre class="text"> Content-Length: 3495 1764 1780 </pre><p id="rfc.section.8.2.p.5">Applications <em class="bcp14">SHOULD</em> use this field to indicate the transfer-length of the message-body, unless this is prohibited by the rules in <a href="#message.length" title="Message Length">Section 3.4</a>. 1765 1781 </p> … … 1771 1787 </p> 1772 1788 <div id="rfc.iref.d.2"></div> 1773 <div id="rfc.iref.h. 5"></div>1789 <div id="rfc.iref.h.8"></div> 1774 1790 <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a> <a id="header.date" href="#header.date">Date</a></h2> 1775 1791 <p id="rfc.section.8.3.p.1">The general-header field "Date" represents the date and time at which the message was originated, having the same semantics 1776 as orig-date in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322. 5"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as described in <a href="#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.1777 </p> 1778 <div id="rfc.figure.u.5 7"></div><pre class="inline"><span id="rfc.iref.g.96"></span><span id="rfc.iref.g.97"></span> <a href="#header.date" class="smpl">Date</a> = "Date" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.date" class="smpl">Date-v</a>1792 as orig-date in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as described in <a href="#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format. 1793 </p> 1794 <div id="rfc.figure.u.56"></div><pre class="inline"><span id="rfc.iref.g.94"></span><span id="rfc.iref.g.95"></span> <a href="#header.date" class="smpl">Date</a> = "Date" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.date" class="smpl">Date-v</a> 1779 1795 <a href="#header.date" class="smpl">Date-v</a> = <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a> 1780 1796 </pre><p id="rfc.section.8.3.p.3">An example is</p> 1781 <div id="rfc.figure.u.5 8"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT1797 <div id="rfc.figure.u.57"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT 1782 1798 </pre><p id="rfc.section.8.3.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases: 1783 1799 </p> … … 1807 1823 of responses without storing separate Expires values for each resource). 1808 1824 </p> 1809 <div id="rfc.iref.h. 6"></div>1810 <div id="rfc.iref.h. 7"></div>1825 <div id="rfc.iref.h.9"></div> 1826 <div id="rfc.iref.h.10"></div> 1811 1827 <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a> <a id="header.host" href="#header.host">Host</a></h2> 1812 1828 <p id="rfc.section.8.4.p.1">The request-header field "Host" specifies the Internet host and port number of the resource being requested, as obtained from … … 1815 1831 a single IP address. 1816 1832 </p> 1817 <div id="rfc.figure.u.5 9"></div><pre class="inline"><span id="rfc.iref.g.98"></span><span id="rfc.iref.g.99"></span> <a href="#header.host" class="smpl">Host</a> = "Host" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.host" class="smpl">Host-v</a>1833 <div id="rfc.figure.u.58"></div><pre class="inline"><span id="rfc.iref.g.96"></span><span id="rfc.iref.g.97"></span> <a href="#header.host" class="smpl">Host</a> = "Host" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.host" class="smpl">Host-v</a> 1818 1834 <a href="#header.host" class="smpl">Host-v</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section 2.6.1</a> 1819 1835 </pre><p id="rfc.section.8.4.p.3">A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP 1820 1836 URL). For example, a request on the origin server for <http://www.example.org/pub/WWW/> would properly include: 1821 1837 </p> 1822 <div id="rfc.figure.u. 60"></div><pre class="text"> GET /pub/WWW/ HTTP/1.11838 <div id="rfc.figure.u.59"></div><pre class="text"> GET /pub/WWW/ HTTP/1.1 1823 1839 Host: www.example.org 1824 1840 </pre><p id="rfc.section.8.4.p.5">A client <em class="bcp14">MUST</em> include a Host header field in all HTTP/1.1 request messages. If the requested URI does not include an Internet host name … … 1829 1845 </p> 1830 1846 <div id="rfc.iref.t.2"></div> 1831 <div id="rfc.iref.h. 8"></div>1847 <div id="rfc.iref.h.11"></div> 1832 1848 <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a> <a id="header.te" href="#header.te">TE</a></h2> 1833 1849 <p id="rfc.section.8.5.p.1">The request-header field "TE" indicates what extension transfer-codings it is willing to accept in the response and whether … … 1835 1851 and/or a comma-separated list of extension transfer-coding names with optional accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section 6.2</a>). 1836 1852 </p> 1837 <div id="rfc.figure.u.6 1"></div><pre class="inline"><span id="rfc.iref.g.100"></span><span id="rfc.iref.g.101"></span><span id="rfc.iref.g.102"></span><span id="rfc.iref.g.103"></span><span id="rfc.iref.g.104"></span> <a href="#header.te" class="smpl">TE</a> = "TE" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.te" class="smpl">TE-v</a>1853 <div id="rfc.figure.u.60"></div><pre class="inline"><span id="rfc.iref.g.98"></span><span id="rfc.iref.g.99"></span><span id="rfc.iref.g.100"></span><span id="rfc.iref.g.101"></span><span id="rfc.iref.g.102"></span> <a href="#header.te" class="smpl">TE</a> = "TE" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.te" class="smpl">TE-v</a> 1838 1854 <a href="#header.te" class="smpl">TE-v</a> = #<a href="#header.te" class="smpl">t-codings</a> 1839 1855 <a href="#header.te" class="smpl">t-codings</a> = "trailers" / ( <a href="#transfer.codings" class="smpl">transfer-extension</a> [ <a href="#header.te" class="smpl">te-params</a> ] ) … … 1844 1860 </p> 1845 1861 <p id="rfc.section.8.5.p.4">Examples of its use are:</p> 1846 <div id="rfc.figure.u.6 2"></div><pre class="text"> TE: deflate1862 <div id="rfc.figure.u.61"></div><pre class="text"> TE: deflate 1847 1863 TE: 1848 1864 TE: trailers, deflate;q=0.5 … … 1876 1892 </p> 1877 1893 <div id="rfc.iref.t.3"></div> 1878 <div id="rfc.iref.h. 9"></div>1894 <div id="rfc.iref.h.12"></div> 1879 1895 <h2 id="rfc.section.8.6"><a href="#rfc.section.8.6">8.6</a> <a id="header.trailer" href="#header.trailer">Trailer</a></h2> 1880 1896 <p id="rfc.section.8.6.p.1">The general field "Trailer" indicates that the given set of header fields is present in the trailer of a message encoded with 1881 1897 chunked transfer-coding. 1882 1898 </p> 1883 <div id="rfc.figure.u.6 3"></div><pre class="inline"><span id="rfc.iref.g.105"></span><span id="rfc.iref.g.106"></span> <a href="#header.trailer" class="smpl">Trailer</a> = "Trailer" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.trailer" class="smpl">Trailer-v</a>1884 <a href="#header.trailer" class="smpl">Trailer-v</a> = 1#<a href="# message.headers" class="smpl">field-name</a>1899 <div id="rfc.figure.u.62"></div><pre class="inline"><span id="rfc.iref.g.103"></span><span id="rfc.iref.g.104"></span> <a href="#header.trailer" class="smpl">Trailer</a> = "Trailer" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.trailer" class="smpl">Trailer-v</a> 1900 <a href="#header.trailer" class="smpl">Trailer-v</a> = 1#<a href="#header.fields" class="smpl">field-name</a> 1885 1901 </pre><p id="rfc.section.8.6.p.3">An HTTP/1.1 message <em class="bcp14">SHOULD</em> include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient 1886 1902 to know which header fields to expect in the trailer. … … 1896 1912 </ul> 1897 1913 <div id="rfc.iref.t.4"></div> 1898 <div id="rfc.iref.h.1 0"></div>1914 <div id="rfc.iref.h.13"></div> 1899 1915 <h2 id="rfc.section.8.7"><a href="#rfc.section.8.7">8.7</a> <a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h2> 1900 1916 <p id="rfc.section.8.7.p.1">The general-header "Transfer-Encoding" field indicates what (if any) type of transformation has been applied to the message … … 1902 1918 transfer-coding is a property of the message, not of the entity. 1903 1919 </p> 1904 <div id="rfc.figure.u.6 4"></div><pre class="inline"><span id="rfc.iref.g.107"></span><span id="rfc.iref.g.108"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = "Transfer-Encoding" ":" <a href="#rule.whitespace" class="smpl">OWS</a>1920 <div id="rfc.figure.u.63"></div><pre class="inline"><span id="rfc.iref.g.105"></span><span id="rfc.iref.g.106"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = "Transfer-Encoding" ":" <a href="#rule.whitespace" class="smpl">OWS</a> 1905 1921 <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding-v</a> 1906 1922 <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding-v</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a> 1907 1923 </pre><p id="rfc.section.8.7.p.3">Transfer-codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section 6.2</a>. An example is: 1908 1924 </p> 1909 <div id="rfc.figure.u.6 5"></div><pre class="text"> Transfer-Encoding: chunked1925 <div id="rfc.figure.u.64"></div><pre class="text"> Transfer-Encoding: chunked 1910 1926 </pre><p id="rfc.section.8.7.p.5">If multiple encodings have been applied to an entity, the transfer-codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other entity-header fields not defined by this specification. 1911 1927 </p> 1912 1928 <p id="rfc.section.8.7.p.6">Many older HTTP/1.0 applications do not understand the Transfer-Encoding header.</p> 1913 1929 <div id="rfc.iref.u.5"></div> 1914 <div id="rfc.iref.h.1 1"></div>1930 <div id="rfc.iref.h.14"></div> 1915 1931 <h2 id="rfc.section.8.8"><a href="#rfc.section.8.8">8.8</a> <a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2> 1916 1932 <p id="rfc.section.8.8.p.1">The general-header "Upgrade" allows the client to specify what additional communication protocols it supports and would like 1917 1933 to use if the server finds it appropriate to switch protocols. The server <em class="bcp14">MUST</em> use the Upgrade header field within a 101 (Switching Protocols) response to indicate which protocol(s) are being switched. 1918 1934 </p> 1919 <div id="rfc.figure.u.6 6"></div><pre class="inline"><span id="rfc.iref.g.109"></span><span id="rfc.iref.g.110"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = "Upgrade" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.upgrade" class="smpl">Upgrade-v</a>1935 <div id="rfc.figure.u.65"></div><pre class="inline"><span id="rfc.iref.g.107"></span><span id="rfc.iref.g.108"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = "Upgrade" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.upgrade" class="smpl">Upgrade-v</a> 1920 1936 <a href="#header.upgrade" class="smpl">Upgrade-v</a> = 1#<a href="#product.tokens" class="smpl">product</a> 1921 1937 </pre><p id="rfc.section.8.8.p.3">For example,</p> 1922 <div id="rfc.figure.u.6 7"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x111938 <div id="rfc.figure.u.66"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 1923 1939 </pre><p id="rfc.section.8.8.p.5">The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible 1924 1940 protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP … … 1943 1959 </p> 1944 1960 <div id="rfc.iref.v.1"></div> 1945 <div id="rfc.iref.h.1 2"></div>1961 <div id="rfc.iref.h.15"></div> 1946 1962 <h2 id="rfc.section.8.9"><a href="#rfc.section.8.9">8.9</a> <a id="header.via" href="#header.via">Via</a></h2> 1947 1963 <p id="rfc.section.8.9.p.1">The general-header field "Via" <em class="bcp14">MUST</em> be used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server 1948 on requests, and between the origin server and the client on responses. It is analogous to the "Received" field defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322. 6"><cite title="Internet Message Format">[RFC5322]</cite></a> and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities1964 on requests, and between the origin server and the client on responses. It is analogous to the "Received" field defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.5"><cite title="Internet Message Format">[RFC5322]</cite></a> and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities 1949 1965 of all senders along the request/response chain. 1950 1966 </p> 1951 <div id="rfc.figure.u.6 8"></div><pre class="inline"><span id="rfc.iref.g.111"></span><span id="rfc.iref.g.112"></span><span id="rfc.iref.g.113"></span><span id="rfc.iref.g.114"></span><span id="rfc.iref.g.115"></span><span id="rfc.iref.g.116"></span><span id="rfc.iref.g.117"></span> <a href="#header.via" class="smpl">Via</a> = "Via" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.via" class="smpl">Via-v</a>1967 <div id="rfc.figure.u.67"></div><pre class="inline"><span id="rfc.iref.g.109"></span><span id="rfc.iref.g.110"></span><span id="rfc.iref.g.111"></span><span id="rfc.iref.g.112"></span><span id="rfc.iref.g.113"></span><span id="rfc.iref.g.114"></span><span id="rfc.iref.g.115"></span> <a href="#header.via" class="smpl">Via</a> = "Via" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.via" class="smpl">Via-v</a> 1952 1968 <a href="#header.via" class="smpl">Via-v</a> = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a> 1953 1969 [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] ) … … 1974 1990 server at www.example.com. The request received by www.example.com would then have the following Via header field: 1975 1991 </p> 1976 <div id="rfc.figure.u.6 9"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)1992 <div id="rfc.figure.u.68"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 1977 1993 </pre><p id="rfc.section.8.9.p.9">Proxies and gateways used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em>, by default, forward the names and ports of hosts within the firewall region. This information <em class="bcp14">SHOULD</em> only be propagated if explicitly enabled. If not enabled, the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host. 1978 1994 </p> … … 1980 1996 For example, 1981 1997 </p> 1982 <div id="rfc.figure.u. 70"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy1998 <div id="rfc.figure.u.69"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 1983 1999 </pre><p id="rfc.section.8.9.p.12">could be collapsed to</p> 1984 <div id="rfc.figure.u.7 1"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy2000 <div id="rfc.figure.u.70"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 1985 2001 </pre><p id="rfc.section.8.9.p.14">Applications <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced 1986 2002 by pseudonyms. Applications <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values. … … 2070 2086 <p id="rfc.section.9.1.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p> 2071 2087 <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a> <a id="uri.scheme.registration" href="#uri.scheme.registration">URI Scheme Registration</a></h2> 2072 <p id="rfc.section.9.2.p.1">The entr y for the "http" URI Scheme in the registry located at <<a href="http://www.iana.org/assignments/uri-schemes.html">http://www.iana.org/assignments/uri-schemes.html</a>> should be updated to point to <a href="#http.uri" title="http URI scheme">Section 2.6.1</a> of this document (see <a href="#RFC4395" id="rfc.xref.RFC4395.1"><cite title="Guidelines and Registration Procedures for New URI Schemes">[RFC4395]</cite></a>).2088 <p id="rfc.section.9.2.p.1">The entries for the "http" and "https" URI Schemes in the registry located at <<a href="http://www.iana.org/assignments/uri-schemes.html">http://www.iana.org/assignments/uri-schemes.html</a>> should be updated to point to Sections <a href="#http.uri" title="http URI scheme">2.6.1</a> and <a href="#https.uri" title="https URI scheme">2.6.2</a> of this document (see <a href="#RFC4395" id="rfc.xref.RFC4395.1"><cite title="Guidelines and Registration Procedures for New URI Schemes">[RFC4395]</cite></a>). 2073 2089 </p> 2074 2090 <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a> <a id="internet.media.type.http" href="#internet.media.type.http">Internet Media Type Registrations</a></h2> … … 2464 2480 <p id="rfc.section.A.p.2">Clients <em class="bcp14">SHOULD</em> be tolerant in parsing the Status-Line and servers tolerant when parsing the Request-Line. In particular, they <em class="bcp14">SHOULD</em> accept any amount of WSP characters between fields, even though only a single SP is required. 2465 2481 </p> 2466 <p id="rfc.section.A.p.3">The line terminator for message-header fields is the sequence CRLF. However, we recommend that applications, when parsing2467 such headers,recognize a single LF as a line terminator and ignore the leading CR.2482 <p id="rfc.section.A.p.3">The line terminator for header fields is the sequence CRLF. However, we recommend that applications, when parsing such headers, 2483 recognize a single LF as a line terminator and ignore the leading CR. 2468 2484 </p> 2469 2485 <p id="rfc.section.A.p.4">The character set of an entity-body <em class="bcp14">SHOULD</em> be labeled as the lowest common denominator of the character codes used within that body, with the exception that not labeling … … 2587 2603 <p id="rfc.section.B.4.p.5">Clarification that the chunk length does not include the count of the octets in the chunk header and trailer. (<a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section 6.2.1</a>) 2588 2604 </p> 2589 <p id="rfc.section.B.4.p.6">Require that invalid whitespace around field-names be rejected. (<a href="# message.headers" title="Message Headers">Section 3.2</a>)2605 <p id="rfc.section.B.4.p.6">Require that invalid whitespace around field-names be rejected. (<a href="#header.fields" title="Header Fields">Section 3.2</a>) 2590 2606 </p> 2591 2607 <p id="rfc.section.B.4.p.7">Update use of abs_path production from RFC1808 to the path-absolute + query components of RFC3986. (<a href="#request-target" title="request-target">Section 4.1.2</a>) … … 2622 2638 </dl> 2623 2639 <h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 2624 <div id="rfc.figure.u.7 2"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS2640 <div id="rfc.figure.u.71"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS 2625 2641 2626 2642 <a href="#abnf.dependencies" class="smpl">Cache-Control</a> = <Cache-Control, defined in [Part6], Section 3.4> … … 2640 2656 <a href="#http.version" class="smpl">HTTP-Version</a> = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT 2641 2657 <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a> = rfc1123-date / obs-date 2642 <a href="#message.types" class="smpl">HTTP-message</a> = Request / Response 2658 <a href="#http.message" class="smpl">HTTP-message</a> = start-line *( header-field CRLF ) CRLF [ 2659 message-body ] 2643 2660 <a href="#header.host" class="smpl">Host</a> = "Host:" OWS Host-v 2644 2661 <a href="#header.host" class="smpl">Host-v</a> = uri-host [ ":" port ] … … 2721 2738 <a href="#abnf.dependencies" class="smpl">entity-header</a> = <entity-header, defined in [Part3], Section 3.1> 2722 2739 2723 <a href="# message.headers" class="smpl">field-content</a> = *( WSP / VCHAR / obs-text )2724 <a href="# message.headers" class="smpl">field-name</a> = token2725 <a href="# message.headers" class="smpl">field-value</a> = *( field-content / OWS )2740 <a href="#header.fields" class="smpl">field-content</a> = *( WSP / VCHAR / obs-text ) 2741 <a href="#header.fields" class="smpl">field-name</a> = token 2742 <a href="#header.fields" class="smpl">field-value</a> = *( field-content / OWS ) 2726 2743 <a href="#uri" class="smpl">fragment</a> = <fragment, defined in [RFC3986], Section 3.5> 2727 2744 2728 2745 <a href="#general.header.fields" class="smpl">general-header</a> = Cache-Control / Connection / Date / Pragma / Trailer 2729 2746 / Transfer-Encoding / Upgrade / Via / Warning 2730 <a href="#message.types" class="smpl">generic-message</a> = start-line *( message-header CRLF ) CRLF [2731 message-body ]2732 2747 2733 2748 <a href="#preferred.date.format" class="smpl">hour</a> = 2DIGIT … … 2739 2754 <a href="#message.body" class="smpl">message-body</a> = entity-body / 2740 2755 <entity-body encoded as per Transfer-Encoding> 2741 <a href="# message.headers" class="smpl">message-header</a> = field-name ":" OWS [ field-value ] OWS2756 <a href="#header.fields" class="smpl">header-field</a> = field-name ":" OWS [ field-value ] OWS 2742 2757 <a href="#preferred.date.format" class="smpl">minute</a> = 2DIGIT 2743 2758 <a href="#preferred.date.format" class="smpl">month</a> = %x4A.61.6E ; Jan … … 2788 2803 2789 2804 <a href="#preferred.date.format" class="smpl">second</a> = 2DIGIT 2790 <a href="# message.types" class="smpl">start-line</a> = Request-Line / Status-Line2805 <a href="#http.message" class="smpl">start-line</a> = Request-Line / Status-Line 2791 2806 2792 2807 <a href="#header.te" class="smpl">t-codings</a> = "trailers" / ( transfer-extension [ te-params ] ) … … 2807 2822 2808 2823 <a href="#preferred.date.format" class="smpl">year</a> = 4DIGIT 2809 </pre> <div id="rfc.figure.u.7 3"></div>2824 </pre> <div id="rfc.figure.u.72"></div> 2810 2825 <p>ABNF diagnostics:</p><pre class="inline">; Chunked-Body defined but not used 2811 2826 ; Content-Length defined but not used … … 3051 3066 <li class="indline1"><tt>absolute-URI</tt> <a class="iref" href="#rfc.iref.g.27"><b>2.6</b></a></li> 3052 3067 <li class="indline1">ALPHA <a class="iref" href="#rfc.iref.g.1"><b>1.2</b></a></li> 3053 <li class="indline1"><tt>asctime-date</tt> <a class="iref" href="#rfc.iref.g. 71"><b>6.1</b></a></li>3054 <li class="indline1"><tt>attribute</tt> <a class="iref" href="#rfc.iref.g.7 5"><b>6.2</b></a></li>3068 <li class="indline1"><tt>asctime-date</tt> <a class="iref" href="#rfc.iref.g.69"><b>6.1</b></a></li> 3069 <li class="indline1"><tt>attribute</tt> <a class="iref" href="#rfc.iref.g.73"><b>6.2</b></a></li> 3055 3070 <li class="indline1"><tt>authority</tt> <a class="iref" href="#rfc.iref.g.28"><b>2.6</b></a></li> 3056 3071 <li class="indline1"><tt>BWS</tt> <a class="iref" href="#rfc.iref.g.15"><b>1.2.2</b></a></li> 3057 <li class="indline1"><tt>chunk</tt> <a class="iref" href="#rfc.iref.g. 80"><b>6.2.1</b></a></li>3058 <li class="indline1"><tt>chunk-data</tt> <a class="iref" href="#rfc.iref.g.8 6"><b>6.2.1</b></a></li>3059 <li class="indline1"><tt>chunk-ext</tt> <a class="iref" href="#rfc.iref.g.8 3"><b>6.2.1</b></a></li>3060 <li class="indline1"><tt>chunk-ext-name</tt> <a class="iref" href="#rfc.iref.g.8 4"><b>6.2.1</b></a></li>3061 <li class="indline1"><tt>chunk-ext-val</tt> <a class="iref" href="#rfc.iref.g.8 5"><b>6.2.1</b></a></li>3062 <li class="indline1"><tt>chunk-size</tt> <a class="iref" href="#rfc.iref.g. 81"><b>6.2.1</b></a></li>3063 <li class="indline1"><tt>Chunked-Body</tt> <a class="iref" href="#rfc.iref.g.7 9"><b>6.2.1</b></a></li>3064 <li class="indline1"><tt>comment</tt> <a class="iref" href="#rfc.iref.g.4 2"><b>3.2</b></a></li>3065 <li class="indline1"><tt>Connection</tt> <a class="iref" href="#rfc.iref.g. 91"><b>8.1</b></a></li>3066 <li class="indline1"><tt>connection-token</tt> <a class="iref" href="#rfc.iref.g.9 3"><b>8.1</b></a></li>3067 <li class="indline1"><tt>Connection-v</tt> <a class="iref" href="#rfc.iref.g.9 2"><b>8.1</b></a></li>3068 <li class="indline1"><tt>Content-Length</tt> <a class="iref" href="#rfc.iref.g.9 4"><b>8.2</b></a></li>3069 <li class="indline1"><tt>Content-Length-v</tt> <a class="iref" href="#rfc.iref.g.9 5"><b>8.2</b></a></li>3072 <li class="indline1"><tt>chunk</tt> <a class="iref" href="#rfc.iref.g.78"><b>6.2.1</b></a></li> 3073 <li class="indline1"><tt>chunk-data</tt> <a class="iref" href="#rfc.iref.g.84"><b>6.2.1</b></a></li> 3074 <li class="indline1"><tt>chunk-ext</tt> <a class="iref" href="#rfc.iref.g.81"><b>6.2.1</b></a></li> 3075 <li class="indline1"><tt>chunk-ext-name</tt> <a class="iref" href="#rfc.iref.g.82"><b>6.2.1</b></a></li> 3076 <li class="indline1"><tt>chunk-ext-val</tt> <a class="iref" href="#rfc.iref.g.83"><b>6.2.1</b></a></li> 3077 <li class="indline1"><tt>chunk-size</tt> <a class="iref" href="#rfc.iref.g.79"><b>6.2.1</b></a></li> 3078 <li class="indline1"><tt>Chunked-Body</tt> <a class="iref" href="#rfc.iref.g.77"><b>6.2.1</b></a></li> 3079 <li class="indline1"><tt>comment</tt> <a class="iref" href="#rfc.iref.g.40"><b>3.2</b></a></li> 3080 <li class="indline1"><tt>Connection</tt> <a class="iref" href="#rfc.iref.g.89"><b>8.1</b></a></li> 3081 <li class="indline1"><tt>connection-token</tt> <a class="iref" href="#rfc.iref.g.91"><b>8.1</b></a></li> 3082 <li class="indline1"><tt>Connection-v</tt> <a class="iref" href="#rfc.iref.g.90"><b>8.1</b></a></li> 3083 <li class="indline1"><tt>Content-Length</tt> <a class="iref" href="#rfc.iref.g.92"><b>8.2</b></a></li> 3084 <li class="indline1"><tt>Content-Length-v</tt> <a class="iref" href="#rfc.iref.g.93"><b>8.2</b></a></li> 3070 3085 <li class="indline1">CR <a class="iref" href="#rfc.iref.g.2"><b>1.2</b></a></li> 3071 3086 <li class="indline1">CRLF <a class="iref" href="#rfc.iref.g.3"><b>1.2</b></a></li> 3072 <li class="indline1"><tt>ctext</tt> <a class="iref" href="#rfc.iref.g.4 3"><b>3.2</b></a></li>3087 <li class="indline1"><tt>ctext</tt> <a class="iref" href="#rfc.iref.g.41"><b>3.2</b></a></li> 3073 3088 <li class="indline1">CTL <a class="iref" href="#rfc.iref.g.4"><b>1.2</b></a></li> 3074 <li class="indline1"><tt>Date</tt> <a class="iref" href="#rfc.iref.g.9 6"><b>8.3</b></a></li>3075 <li class="indline1"><tt>Date-v</tt> <a class="iref" href="#rfc.iref.g.9 7"><b>8.3</b></a></li>3076 <li class="indline1"><tt>date1</tt> <a class="iref" href="#rfc.iref.g.5 8"><b>6.1</b></a></li>3077 <li class="indline1"><tt>date2</tt> <a class="iref" href="#rfc.iref.g.7 7"><b>6.2</b></a></li>3078 <li class="indline1"><tt>date3</tt> <a class="iref" href="#rfc.iref.g.7 8"><b>6.2</b></a></li>3079 <li class="indline1"><tt>day</tt> <a class="iref" href="#rfc.iref.g.6 5"><b>6.1</b></a></li>3080 <li class="indline1"><tt>day-name</tt> <a class="iref" href="#rfc.iref.g.6 3"><b>6.1</b></a></li>3081 <li class="indline1"><tt>day-name-l</tt> <a class="iref" href="#rfc.iref.g.6 4"><b>6.1</b></a></li>3089 <li class="indline1"><tt>Date</tt> <a class="iref" href="#rfc.iref.g.94"><b>8.3</b></a></li> 3090 <li class="indline1"><tt>Date-v</tt> <a class="iref" href="#rfc.iref.g.95"><b>8.3</b></a></li> 3091 <li class="indline1"><tt>date1</tt> <a class="iref" href="#rfc.iref.g.56"><b>6.1</b></a></li> 3092 <li class="indline1"><tt>date2</tt> <a class="iref" href="#rfc.iref.g.75"><b>6.2</b></a></li> 3093 <li class="indline1"><tt>date3</tt> <a class="iref" href="#rfc.iref.g.76"><b>6.2</b></a></li> 3094 <li class="indline1"><tt>day</tt> <a class="iref" href="#rfc.iref.g.63"><b>6.1</b></a></li> 3095 <li class="indline1"><tt>day-name</tt> <a class="iref" href="#rfc.iref.g.61"><b>6.1</b></a></li> 3096 <li class="indline1"><tt>day-name-l</tt> <a class="iref" href="#rfc.iref.g.62"><b>6.1</b></a></li> 3082 3097 <li class="indline1">DIGIT <a class="iref" href="#rfc.iref.g.5"><b>1.2</b></a></li> 3083 3098 <li class="indline1">DQUOTE <a class="iref" href="#rfc.iref.g.6"><b>1.2</b></a></li> 3084 <li class="indline1"><tt>extension-code</tt> <a class="iref" href="#rfc.iref.g.5 4"><b>5.1.1</b></a></li>3085 <li class="indline1"><tt>extension-method</tt> <a class="iref" href="#rfc.iref.g.4 9"><b>4.1.1</b></a></li>3086 <li class="indline1"><tt>field-content</tt> <a class="iref" href="#rfc.iref.g. 41"><b>3.2</b></a></li>3087 <li class="indline1"><tt>field-name</tt> <a class="iref" href="#rfc.iref.g.3 9"><b>3.2</b></a></li>3088 <li class="indline1"><tt>field-value</tt> <a class="iref" href="#rfc.iref.g. 40"><b>3.2</b></a></li>3089 <li class="indline1"><tt>general-header</tt> <a class="iref" href="#rfc.iref.g.4 5"><b>3.5</b></a></li>3090 <li class="indline1"><tt> generic-message</tt> <a class="iref" href="#rfc.iref.g.36"><b>3.1</b></a></li>3091 <li class="indline1"><tt> GMT</tt> <a class="iref" href="#rfc.iref.g.68"><b>6.1</b></a></li>3099 <li class="indline1"><tt>extension-code</tt> <a class="iref" href="#rfc.iref.g.52"><b>5.1.1</b></a></li> 3100 <li class="indline1"><tt>extension-method</tt> <a class="iref" href="#rfc.iref.g.47"><b>4.1.1</b></a></li> 3101 <li class="indline1"><tt>field-content</tt> <a class="iref" href="#rfc.iref.g.39"><b>3.2</b></a></li> 3102 <li class="indline1"><tt>field-name</tt> <a class="iref" href="#rfc.iref.g.37"><b>3.2</b></a></li> 3103 <li class="indline1"><tt>field-value</tt> <a class="iref" href="#rfc.iref.g.38"><b>3.2</b></a></li> 3104 <li class="indline1"><tt>general-header</tt> <a class="iref" href="#rfc.iref.g.43"><b>3.5</b></a></li> 3105 <li class="indline1"><tt>GMT</tt> <a class="iref" href="#rfc.iref.g.66"><b>6.1</b></a></li> 3106 <li class="indline1"><tt>header-field</tt> <a class="iref" href="#rfc.iref.g.36"><b>3.2</b></a></li> 3092 3107 <li class="indline1">HEXDIG <a class="iref" href="#rfc.iref.g.7"><b>1.2</b></a></li> 3093 <li class="indline1"><tt>Host</tt> <a class="iref" href="#rfc.iref.g.9 8"><b>8.4</b></a></li>3094 <li class="indline1"><tt>Host-v</tt> <a class="iref" href="#rfc.iref.g.9 9"><b>8.4</b></a></li>3095 <li class="indline1"><tt>hour</tt> <a class="iref" href="#rfc.iref.g. 60"><b>6.1</b></a></li>3096 <li class="indline1"><tt>HTTP-date</tt> <a class="iref" href="#rfc.iref.g.5 6"><b>6.1</b></a></li>3097 <li class="indline1"><tt>HTTP-message</tt> <a class="iref" href="#rfc.iref.g.35"><b>3 .1</b></a></li>3108 <li class="indline1"><tt>Host</tt> <a class="iref" href="#rfc.iref.g.96"><b>8.4</b></a></li> 3109 <li class="indline1"><tt>Host-v</tt> <a class="iref" href="#rfc.iref.g.97"><b>8.4</b></a></li> 3110 <li class="indline1"><tt>hour</tt> <a class="iref" href="#rfc.iref.g.58"><b>6.1</b></a></li> 3111 <li class="indline1"><tt>HTTP-date</tt> <a class="iref" href="#rfc.iref.g.54"><b>6.1</b></a></li> 3112 <li class="indline1"><tt>HTTP-message</tt> <a class="iref" href="#rfc.iref.g.35"><b>3</b></a></li> 3098 3113 <li class="indline1"><tt>HTTP-Prot-Name</tt> <a class="iref" href="#rfc.iref.g.25"><b>2.5</b></a></li> 3099 3114 <li class="indline1"><tt>http-URI</tt> <a class="iref" href="#rfc.iref.g.33"><b>2.6.1</b></a></li> 3100 3115 <li class="indline1"><tt>HTTP-Version</tt> <a class="iref" href="#rfc.iref.g.24"><b>2.5</b></a></li> 3101 3116 <li class="indline1"><tt>https-URI</tt> <a class="iref" href="#rfc.iref.g.34"><b>2.6.2</b></a></li> 3102 <li class="indline1"><tt>last-chunk</tt> <a class="iref" href="#rfc.iref.g.8 2"><b>6.2.1</b></a></li>3117 <li class="indline1"><tt>last-chunk</tt> <a class="iref" href="#rfc.iref.g.80"><b>6.2.1</b></a></li> 3103 3118 <li class="indline1">LF <a class="iref" href="#rfc.iref.g.8"><b>1.2</b></a></li> 3104 <li class="indline1"><tt>message-body</tt> <a class="iref" href="#rfc.iref.g.44"><b>3.3</b></a></li> 3105 <li class="indline1"><tt>message-header</tt> <a class="iref" href="#rfc.iref.g.38"><b>3.2</b></a></li> 3106 <li class="indline1"><tt>Method</tt> <a class="iref" href="#rfc.iref.g.48"><b>4.1.1</b></a></li> 3107 <li class="indline1"><tt>minute</tt> <a class="iref" href="#rfc.iref.g.61"><b>6.1</b></a></li> 3108 <li class="indline1"><tt>month</tt> <a class="iref" href="#rfc.iref.g.66"><b>6.1</b></a></li> 3109 <li class="indline1"><tt>obs-date</tt> <a class="iref" href="#rfc.iref.g.69"><b>6.1</b></a></li> 3119 <li class="indline1"><tt>message-body</tt> <a class="iref" href="#rfc.iref.g.42"><b>3.3</b></a></li> 3120 <li class="indline1"><tt>Method</tt> <a class="iref" href="#rfc.iref.g.46"><b>4.1.1</b></a></li> 3121 <li class="indline1"><tt>minute</tt> <a class="iref" href="#rfc.iref.g.59"><b>6.1</b></a></li> 3122 <li class="indline1"><tt>month</tt> <a class="iref" href="#rfc.iref.g.64"><b>6.1</b></a></li> 3123 <li class="indline1"><tt>obs-date</tt> <a class="iref" href="#rfc.iref.g.67"><b>6.1</b></a></li> 3110 3124 <li class="indline1"><tt>obs-text</tt> <a class="iref" href="#rfc.iref.g.20"><b>1.2.2</b></a></li> 3111 3125 <li class="indline1">OCTET <a class="iref" href="#rfc.iref.g.9"><b>1.2</b></a></li> … … 3113 3127 <li class="indline1"><tt>path-absolute</tt> <a class="iref" href="#rfc.iref.g.29"><b>2.6</b></a></li> 3114 3128 <li class="indline1"><tt>port</tt> <a class="iref" href="#rfc.iref.g.30"><b>2.6</b></a></li> 3115 <li class="indline1"><tt>product</tt> <a class="iref" href="#rfc.iref.g.8 8"><b>6.3</b></a></li>3116 <li class="indline1"><tt>product-version</tt> <a class="iref" href="#rfc.iref.g.8 9"><b>6.3</b></a></li>3117 <li class="indline1"><tt>protocol-name</tt> <a class="iref" href="#rfc.iref.g.11 4"><b>8.9</b></a></li>3118 <li class="indline1"><tt>protocol-version</tt> <a class="iref" href="#rfc.iref.g.11 5"><b>8.9</b></a></li>3119 <li class="indline1"><tt>pseudonym</tt> <a class="iref" href="#rfc.iref.g.11 7"><b>8.9</b></a></li>3129 <li class="indline1"><tt>product</tt> <a class="iref" href="#rfc.iref.g.86"><b>6.3</b></a></li> 3130 <li class="indline1"><tt>product-version</tt> <a class="iref" href="#rfc.iref.g.87"><b>6.3</b></a></li> 3131 <li class="indline1"><tt>protocol-name</tt> <a class="iref" href="#rfc.iref.g.112"><b>8.9</b></a></li> 3132 <li class="indline1"><tt>protocol-version</tt> <a class="iref" href="#rfc.iref.g.113"><b>8.9</b></a></li> 3133 <li class="indline1"><tt>pseudonym</tt> <a class="iref" href="#rfc.iref.g.115"><b>8.9</b></a></li> 3120 3134 <li class="indline1"><tt>qdtext</tt> <a class="iref" href="#rfc.iref.g.19"><b>1.2.2</b></a></li> 3121 3135 <li class="indline1"><tt>query</tt> <a class="iref" href="#rfc.iref.g.31"><b>2.6</b></a></li> … … 3123 3137 <li class="indline1"><tt>quoted-string</tt> <a class="iref" href="#rfc.iref.g.18"><b>1.2.2</b></a></li> 3124 3138 <li class="indline1"><tt>quoted-text</tt> <a class="iref" href="#rfc.iref.g.21"><b>1.2.2</b></a></li> 3125 <li class="indline1"><tt>qvalue</tt> <a class="iref" href="#rfc.iref.g. 90"><b>6.4</b></a></li>3126 <li class="indline1"><tt>Reason-Phrase</tt> <a class="iref" href="#rfc.iref.g.5 5"><b>5.1.1</b></a></li>3127 <li class="indline1"><tt>received-by</tt> <a class="iref" href="#rfc.iref.g.11 6"><b>8.9</b></a></li>3128 <li class="indline1"><tt>received-protocol</tt> <a class="iref" href="#rfc.iref.g.11 3"><b>8.9</b></a></li>3129 <li class="indline1"><tt>Request</tt> <a class="iref" href="#rfc.iref.g.4 6"><b>4</b></a></li>3130 <li class="indline1"><tt>Request-Line</tt> <a class="iref" href="#rfc.iref.g.4 7"><b>4.1</b></a></li>3131 <li class="indline1"><tt>request-target</tt> <a class="iref" href="#rfc.iref.g. 50"><b>4.1.2</b></a></li>3132 <li class="indline1"><tt>Response</tt> <a class="iref" href="#rfc.iref.g. 51"><b>5</b></a></li>3133 <li class="indline1"><tt>rfc1123-date</tt> <a class="iref" href="#rfc.iref.g.5 7"><b>6.1</b></a></li>3134 <li class="indline1"><tt>rfc850-date</tt> <a class="iref" href="#rfc.iref.g. 70"><b>6.1</b></a></li>3139 <li class="indline1"><tt>qvalue</tt> <a class="iref" href="#rfc.iref.g.88"><b>6.4</b></a></li> 3140 <li class="indline1"><tt>Reason-Phrase</tt> <a class="iref" href="#rfc.iref.g.53"><b>5.1.1</b></a></li> 3141 <li class="indline1"><tt>received-by</tt> <a class="iref" href="#rfc.iref.g.114"><b>8.9</b></a></li> 3142 <li class="indline1"><tt>received-protocol</tt> <a class="iref" href="#rfc.iref.g.111"><b>8.9</b></a></li> 3143 <li class="indline1"><tt>Request</tt> <a class="iref" href="#rfc.iref.g.44"><b>4</b></a></li> 3144 <li class="indline1"><tt>Request-Line</tt> <a class="iref" href="#rfc.iref.g.45"><b>4.1</b></a></li> 3145 <li class="indline1"><tt>request-target</tt> <a class="iref" href="#rfc.iref.g.48"><b>4.1.2</b></a></li> 3146 <li class="indline1"><tt>Response</tt> <a class="iref" href="#rfc.iref.g.49"><b>5</b></a></li> 3147 <li class="indline1"><tt>rfc1123-date</tt> <a class="iref" href="#rfc.iref.g.55"><b>6.1</b></a></li> 3148 <li class="indline1"><tt>rfc850-date</tt> <a class="iref" href="#rfc.iref.g.68"><b>6.1</b></a></li> 3135 3149 <li class="indline1"><tt>RWS</tt> <a class="iref" href="#rfc.iref.g.14"><b>1.2.2</b></a></li> 3136 <li class="indline1"><tt>second</tt> <a class="iref" href="#rfc.iref.g.6 2"><b>6.1</b></a></li>3150 <li class="indline1"><tt>second</tt> <a class="iref" href="#rfc.iref.g.60"><b>6.1</b></a></li> 3137 3151 <li class="indline1">SP <a class="iref" href="#rfc.iref.g.10"><b>1.2</b></a></li> 3138 <li class="indline1"><tt>start-line</tt> <a class="iref" href="#rfc.iref.g.37"><b>3.1</b></a></li> 3139 <li class="indline1"><tt>Status-Code</tt> <a class="iref" href="#rfc.iref.g.53"><b>5.1.1</b></a></li> 3140 <li class="indline1"><tt>Status-Line</tt> <a class="iref" href="#rfc.iref.g.52"><b>5.1</b></a></li> 3141 <li class="indline1"><tt>t-codings</tt> <a class="iref" href="#rfc.iref.g.102"><b>8.5</b></a></li> 3152 <li class="indline1"><tt>Status-Code</tt> <a class="iref" href="#rfc.iref.g.51"><b>5.1.1</b></a></li> 3153 <li class="indline1"><tt>Status-Line</tt> <a class="iref" href="#rfc.iref.g.50"><b>5.1</b></a></li> 3154 <li class="indline1"><tt>t-codings</tt> <a class="iref" href="#rfc.iref.g.100"><b>8.5</b></a></li> 3142 3155 <li class="indline1"><tt>tchar</tt> <a class="iref" href="#rfc.iref.g.17"><b>1.2.2</b></a></li> 3143 <li class="indline1"><tt>TE</tt> <a class="iref" href="#rfc.iref.g. 100"><b>8.5</b></a></li>3144 <li class="indline1"><tt>te-ext</tt> <a class="iref" href="#rfc.iref.g.10 4"><b>8.5</b></a></li>3145 <li class="indline1"><tt>te-params</tt> <a class="iref" href="#rfc.iref.g.10 3"><b>8.5</b></a></li>3146 <li class="indline1"><tt>TE-v</tt> <a class="iref" href="#rfc.iref.g. 101"><b>8.5</b></a></li>3147 <li class="indline1"><tt>time-of-day</tt> <a class="iref" href="#rfc.iref.g.5 9"><b>6.1</b></a></li>3156 <li class="indline1"><tt>TE</tt> <a class="iref" href="#rfc.iref.g.98"><b>8.5</b></a></li> 3157 <li class="indline1"><tt>te-ext</tt> <a class="iref" href="#rfc.iref.g.102"><b>8.5</b></a></li> 3158 <li class="indline1"><tt>te-params</tt> <a class="iref" href="#rfc.iref.g.101"><b>8.5</b></a></li> 3159 <li class="indline1"><tt>TE-v</tt> <a class="iref" href="#rfc.iref.g.99"><b>8.5</b></a></li> 3160 <li class="indline1"><tt>time-of-day</tt> <a class="iref" href="#rfc.iref.g.57"><b>6.1</b></a></li> 3148 3161 <li class="indline1"><tt>token</tt> <a class="iref" href="#rfc.iref.g.16"><b>1.2.2</b></a></li> 3149 <li class="indline1"><tt>Trailer</tt> <a class="iref" href="#rfc.iref.g.10 5"><b>8.6</b></a></li>3150 <li class="indline1"><tt>trailer-part</tt> <a class="iref" href="#rfc.iref.g.8 7"><b>6.2.1</b></a></li>3151 <li class="indline1"><tt>Trailer-v</tt> <a class="iref" href="#rfc.iref.g.10 6"><b>8.6</b></a></li>3152 <li class="indline1"><tt>transfer-coding</tt> <a class="iref" href="#rfc.iref.g.7 2"><b>6.2</b></a></li>3153 <li class="indline1"><tt>Transfer-Encoding</tt> <a class="iref" href="#rfc.iref.g.10 7"><b>8.7</b></a></li>3154 <li class="indline1"><tt>Transfer-Encoding-v</tt> <a class="iref" href="#rfc.iref.g.10 8"><b>8.7</b></a></li>3155 <li class="indline1"><tt>transfer-extension</tt> <a class="iref" href="#rfc.iref.g.7 3"><b>6.2</b></a></li>3156 <li class="indline1"><tt>transfer-parameter</tt> <a class="iref" href="#rfc.iref.g.7 4"><b>6.2</b></a></li>3157 <li class="indline1"><tt>Upgrade</tt> <a class="iref" href="#rfc.iref.g.10 9"><b>8.8</b></a></li>3158 <li class="indline1"><tt>Upgrade-v</tt> <a class="iref" href="#rfc.iref.g.1 10"><b>8.8</b></a></li>3162 <li class="indline1"><tt>Trailer</tt> <a class="iref" href="#rfc.iref.g.103"><b>8.6</b></a></li> 3163 <li class="indline1"><tt>trailer-part</tt> <a class="iref" href="#rfc.iref.g.85"><b>6.2.1</b></a></li> 3164 <li class="indline1"><tt>Trailer-v</tt> <a class="iref" href="#rfc.iref.g.104"><b>8.6</b></a></li> 3165 <li class="indline1"><tt>transfer-coding</tt> <a class="iref" href="#rfc.iref.g.70"><b>6.2</b></a></li> 3166 <li class="indline1"><tt>Transfer-Encoding</tt> <a class="iref" href="#rfc.iref.g.105"><b>8.7</b></a></li> 3167 <li class="indline1"><tt>Transfer-Encoding-v</tt> <a class="iref" href="#rfc.iref.g.106"><b>8.7</b></a></li> 3168 <li class="indline1"><tt>transfer-extension</tt> <a class="iref" href="#rfc.iref.g.71"><b>6.2</b></a></li> 3169 <li class="indline1"><tt>transfer-parameter</tt> <a class="iref" href="#rfc.iref.g.72"><b>6.2</b></a></li> 3170 <li class="indline1"><tt>Upgrade</tt> <a class="iref" href="#rfc.iref.g.107"><b>8.8</b></a></li> 3171 <li class="indline1"><tt>Upgrade-v</tt> <a class="iref" href="#rfc.iref.g.108"><b>8.8</b></a></li> 3159 3172 <li class="indline1"><tt>uri-host</tt> <a class="iref" href="#rfc.iref.g.32"><b>2.6</b></a></li> 3160 3173 <li class="indline1"><tt>URI-reference</tt> <a class="iref" href="#rfc.iref.g.26"><b>2.6</b></a></li> 3161 <li class="indline1"><tt>value</tt> <a class="iref" href="#rfc.iref.g.7 6"><b>6.2</b></a></li>3174 <li class="indline1"><tt>value</tt> <a class="iref" href="#rfc.iref.g.74"><b>6.2</b></a></li> 3162 3175 <li class="indline1">VCHAR <a class="iref" href="#rfc.iref.g.11"><b>1.2</b></a></li> 3163 <li class="indline1"><tt>Via</tt> <a class="iref" href="#rfc.iref.g.1 11"><b>8.9</b></a></li>3164 <li class="indline1"><tt>Via-v</tt> <a class="iref" href="#rfc.iref.g.11 2"><b>8.9</b></a></li>3176 <li class="indline1"><tt>Via</tt> <a class="iref" href="#rfc.iref.g.109"><b>8.9</b></a></li> 3177 <li class="indline1"><tt>Via-v</tt> <a class="iref" href="#rfc.iref.g.110"><b>8.9</b></a></li> 3165 3178 <li class="indline1">WSP <a class="iref" href="#rfc.iref.g.12"><b>1.2</b></a></li> 3166 <li class="indline1"><tt>year</tt> <a class="iref" href="#rfc.iref.g.6 7"><b>6.1</b></a></li>3179 <li class="indline1"><tt>year</tt> <a class="iref" href="#rfc.iref.g.65"><b>6.1</b></a></li> 3167 3180 </ul> 3168 3181 </li> … … 3170 3183 </li> 3171 3184 <li class="indline0"><a id="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul class="ind"> 3185 <li class="indline1">header field <a class="iref" href="#rfc.iref.h.5">3</a></li> 3186 <li class="indline1">header section <a class="iref" href="#rfc.iref.h.3">3</a></li> 3187 <li class="indline1">headers <a class="iref" href="#rfc.iref.h.4">3</a></li> 3172 3188 <li class="indline1">Headers 3173 3189 <ul class="ind"> 3174 <li class="indline1">Connection <a class="iref" href="#rfc.xref.header.connection.1">3.5</a>, <a class="iref" href="#rfc.xref.header.connection.2">7.1.2</a>, <a class="iref" href="#rfc.xref.header.connection.3">7.1.3</a>, <a class="iref" href="#rfc.iref.h. 3"><b>8.1</b></a>, <a class="iref" href="#rfc.xref.header.connection.4">8.5</a>, <a class="iref" href="#rfc.xref.header.connection.5">8.8</a>, <a class="iref" href="#rfc.xref.header.connection.6">9.1</a>, <a class="iref" href="#rfc.xref.header.connection.7">B.2</a>, <a class="iref" href="#rfc.xref.header.connection.8">B.4</a></li>3175 <li class="indline1">Content-Length <a class="iref" href="#rfc.xref.header.content-length.1">3.4</a>, <a class="iref" href="#rfc.iref.h. 4"><b>8.2</b></a>, <a class="iref" href="#rfc.xref.header.content-length.2">9.1</a>, <a class="iref" href="#rfc.xref.header.content-length.3">B.3</a></li>3176 <li class="indline1">Date <a class="iref" href="#rfc.xref.header.date.1">3.5</a>, <a class="iref" href="#rfc.iref.h. 5"><b>8.3</b></a>, <a class="iref" href="#rfc.xref.header.date.2">9.1</a></li>3177 <li class="indline1">Host <a class="iref" href="#rfc.iref.h. 7"><b>8.4</b></a>, <a class="iref" href="#rfc.xref.header.host.1">9.1</a>, <a class="iref" href="#rfc.xref.header.host.2">B.1.1</a></li>3178 <li class="indline1">TE <a class="iref" href="#rfc.xref.header.te.1">6.2</a>, <a class="iref" href="#rfc.xref.header.te.2">6.2.1</a>, <a class="iref" href="#rfc.xref.header.te.3">6.4</a>, <a class="iref" href="#rfc.iref.h. 8"><b>8.5</b></a>, <a class="iref" href="#rfc.xref.header.te.4">9.1</a>, <a class="iref" href="#rfc.xref.header.te.5">B.3</a></li>3179 <li class="indline1">Trailer <a class="iref" href="#rfc.xref.header.trailer.1">3.5</a>, <a class="iref" href="#rfc.xref.header.trailer.2">6.2.1</a>, <a class="iref" href="#rfc.iref.h. 9"><b>8.6</b></a>, <a class="iref" href="#rfc.xref.header.trailer.3">9.1</a></li>3180 <li class="indline1">Transfer-Encoding <a class="iref" href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.2">3.4</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.3">3.5</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.4">6.2</a>, <a class="iref" href="#rfc.iref.h.1 0"><b>8.7</b></a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.5">9.1</a></li>3181 <li class="indline1">Upgrade <a class="iref" href="#rfc.xref.header.upgrade.1">3.5</a>, <a class="iref" href="#rfc.iref.h.1 1"><b>8.8</b></a>, <a class="iref" href="#rfc.xref.header.upgrade.2">9.1</a></li>3182 <li class="indline1">Via <a class="iref" href="#rfc.xref.header.via.1">3.5</a>, <a class="iref" href="#rfc.iref.h.1 2"><b>8.9</b></a>, <a class="iref" href="#rfc.xref.header.via.2">9.1</a></li>3190 <li class="indline1">Connection <a class="iref" href="#rfc.xref.header.connection.1">3.5</a>, <a class="iref" href="#rfc.xref.header.connection.2">7.1.2</a>, <a class="iref" href="#rfc.xref.header.connection.3">7.1.3</a>, <a class="iref" href="#rfc.iref.h.6"><b>8.1</b></a>, <a class="iref" href="#rfc.xref.header.connection.4">8.5</a>, <a class="iref" href="#rfc.xref.header.connection.5">8.8</a>, <a class="iref" href="#rfc.xref.header.connection.6">9.1</a>, <a class="iref" href="#rfc.xref.header.connection.7">B.2</a>, <a class="iref" href="#rfc.xref.header.connection.8">B.4</a></li> 3191 <li class="indline1">Content-Length <a class="iref" href="#rfc.xref.header.content-length.1">3.4</a>, <a class="iref" href="#rfc.iref.h.7"><b>8.2</b></a>, <a class="iref" href="#rfc.xref.header.content-length.2">9.1</a>, <a class="iref" href="#rfc.xref.header.content-length.3">B.3</a></li> 3192 <li class="indline1">Date <a class="iref" href="#rfc.xref.header.date.1">3.5</a>, <a class="iref" href="#rfc.iref.h.8"><b>8.3</b></a>, <a class="iref" href="#rfc.xref.header.date.2">9.1</a></li> 3193 <li class="indline1">Host <a class="iref" href="#rfc.iref.h.10"><b>8.4</b></a>, <a class="iref" href="#rfc.xref.header.host.1">9.1</a>, <a class="iref" href="#rfc.xref.header.host.2">B.1.1</a></li> 3194 <li class="indline1">TE <a class="iref" href="#rfc.xref.header.te.1">6.2</a>, <a class="iref" href="#rfc.xref.header.te.2">6.2.1</a>, <a class="iref" href="#rfc.xref.header.te.3">6.4</a>, <a class="iref" href="#rfc.iref.h.11"><b>8.5</b></a>, <a class="iref" href="#rfc.xref.header.te.4">9.1</a>, <a class="iref" href="#rfc.xref.header.te.5">B.3</a></li> 3195 <li class="indline1">Trailer <a class="iref" href="#rfc.xref.header.trailer.1">3.5</a>, <a class="iref" href="#rfc.xref.header.trailer.2">6.2.1</a>, <a class="iref" href="#rfc.iref.h.12"><b>8.6</b></a>, <a class="iref" href="#rfc.xref.header.trailer.3">9.1</a></li> 3196 <li class="indline1">Transfer-Encoding <a class="iref" href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.2">3.4</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.3">3.5</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.4">6.2</a>, <a class="iref" href="#rfc.iref.h.13"><b>8.7</b></a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.5">9.1</a></li> 3197 <li class="indline1">Upgrade <a class="iref" href="#rfc.xref.header.upgrade.1">3.5</a>, <a class="iref" href="#rfc.iref.h.14"><b>8.8</b></a>, <a class="iref" href="#rfc.xref.header.upgrade.2">9.1</a></li> 3198 <li class="indline1">Via <a class="iref" href="#rfc.xref.header.via.1">3.5</a>, <a class="iref" href="#rfc.iref.h.15"><b>8.9</b></a>, <a class="iref" href="#rfc.xref.header.via.2">9.1</a></li> 3183 3199 </ul> 3184 3200 </li> 3185 <li class="indline1">Host header <a class="iref" href="#rfc.iref.h. 6"><b>8.4</b></a>, <a class="iref" href="#rfc.xref.header.host.1">9.1</a>, <a class="iref" href="#rfc.xref.header.host.2">B.1.1</a></li>3201 <li class="indline1">Host header <a class="iref" href="#rfc.iref.h.9"><b>8.4</b></a>, <a class="iref" href="#rfc.xref.header.host.1">9.1</a>, <a class="iref" href="#rfc.xref.header.host.2">B.1.1</a></li> 3186 3202 <li class="indline1">http URI scheme <a class="iref" href="#rfc.iref.h.1"><b>2.6.1</b></a></li> 3187 3203 <li class="indline1">https URI scheme <a class="iref" href="#rfc.iref.h.2">2.6.2</a></li> … … 3243 3259 <li class="indline1"><em>Part5</em> <a class="iref" href="#Part5"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.Part5.1">B.3</a></li> 3244 3260 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.4">2.3</a>, <a class="iref" href="#rfc.xref.Part6.5">3.5</a>, <a class="iref" href="#rfc.xref.Part6.6">3.5</a>, <a class="iref" href="#rfc.xref.Part6.7">3.5</a>, <a class="iref" href="#Part6"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.Part6.8">B.3</a><ul class="ind"> 3245 <li class="indline1"><em>Section 1</em> <a class="iref" href="#rfc.xref.Part6.4">2.3</a></li>3261 <li class="indline1"><em>Section 2</em> <a class="iref" href="#rfc.xref.Part6.4">2.3</a></li> 3246 3262 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part6.5">3.5</a></li> 3247 3263 <li class="indline1"><em>Section 3.4</em> <a class="iref" href="#rfc.xref.Part6.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.6">3.5</a></li> … … 3262 3278 <li class="indline1"><em>RFC1900</em> <a class="iref" href="#rfc.xref.RFC1900.1">10.4</a>, <a class="iref" href="#RFC1900"><b>12.2</b></a></li> 3263 3279 <li class="indline1"><em>RFC1945</em> <a class="iref" href="#RFC1945"><b>12.2</b></a>, <a class="iref" href="#rfc.xref.RFC1945.1">B</a></li> 3264 <li class="indline1"><em>RFC2045</em> <a class="iref" href="#rfc.xref.RFC2045.1">1</a>, <a class="iref" href="#rfc.xref.RFC2045.2">6.2</a>, <a class="iref" href="#rfc.xref.RFC2045.3">11</a>, <a class="iref" href="#RFC2045"><b>12.2</b></a></li> 3280 <li class="indline1"><em>RFC2045</em> <a class="iref" href="#rfc.xref.RFC2045.1">1</a>, <a class="iref" href="#rfc.xref.RFC2045.2">6.2</a>, <a class="iref" href="#rfc.xref.RFC2045.3">11</a>, <a class="iref" href="#RFC2045"><b>12.2</b></a><ul class="ind"> 3281 <li class="indline1"><em>Section 6</em> <a class="iref" href="#rfc.xref.RFC2045.2">6.2</a></li> 3282 </ul> 3283 </li> 3265 3284 <li class="indline1"><em>RFC2047</em> <a class="iref" href="#rfc.xref.RFC2047.1">3.2</a>, <a class="iref" href="#RFC2047"><b>12.2</b></a></li> 3266 3285 <li class="indline1"><em>RFC2068</em> <a class="iref" href="#rfc.xref.RFC2068.1">2.5</a>, <a class="iref" href="#rfc.xref.RFC2068.2">7.1.3</a>, <a class="iref" href="#rfc.xref.RFC2068.3">7.2.3</a>, <a class="iref" href="#rfc.xref.RFC2068.4">11</a>, <a class="iref" href="#RFC2068"><b>12.2</b></a>, <a class="iref" href="#rfc.xref.RFC2068.5">B</a>, <a class="iref" href="#rfc.xref.RFC2068.6">B.2</a><ul class="ind"> … … 3296 3315 </ul> 3297 3316 </li> 3298 <li class="indline1"><em>RFC5322</em> <a class="iref" href="#rfc.xref.RFC5322.1">1</a>, <a class="iref" href="#rfc.xref.RFC5322.2">3.1</a>, <a class="iref" href="#rfc.xref.RFC5322.3">3.2</a>, <a class="iref" href="#rfc.xref.RFC5322.4">6.1</a>, <a class="iref" href="#rfc.xref.RFC5322.5">8.3</a>, <a class="iref" href="#rfc.xref.RFC5322.6">8.9</a>, <a class="iref" href="#RFC5322"><b>12.2</b></a><ul class="ind"> 3299 <li class="indline1"><em>Section 2.1</em> <a class="iref" href="#rfc.xref.RFC5322.3">3.2</a></li> 3300 <li class="indline1"><em>Section 3.3</em> <a class="iref" href="#rfc.xref.RFC5322.4">6.1</a></li> 3301 <li class="indline1"><em>Section 3.6.1</em> <a class="iref" href="#rfc.xref.RFC5322.5">8.3</a></li> 3302 <li class="indline1"><em>Section 3.6.7</em> <a class="iref" href="#rfc.xref.RFC5322.6">8.9</a></li> 3317 <li class="indline1"><em>RFC5322</em> <a class="iref" href="#rfc.xref.RFC5322.1">1</a>, <a class="iref" href="#rfc.xref.RFC5322.2">3</a>, <a class="iref" href="#rfc.xref.RFC5322.3">6.1</a>, <a class="iref" href="#rfc.xref.RFC5322.4">8.3</a>, <a class="iref" href="#rfc.xref.RFC5322.5">8.9</a>, <a class="iref" href="#RFC5322"><b>12.2</b></a><ul class="ind"> 3318 <li class="indline1"><em>Section 3.3</em> <a class="iref" href="#rfc.xref.RFC5322.3">6.1</a></li> 3319 <li class="indline1"><em>Section 3.6.1</em> <a class="iref" href="#rfc.xref.RFC5322.4">8.3</a></li> 3320 <li class="indline1"><em>Section 3.6.7</em> <a class="iref" href="#rfc.xref.RFC5322.5">8.9</a></li> 3303 3321 </ul> 3304 3322 </li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r646 r647 427 427 ; "bad" whitespace 428 428 <x:ref>obs-fold</x:ref> = <x:ref>CRLF</x:ref> 429 ; see <xref target=" message.headers"/>429 ; see <xref target="header.fields"/> 430 430 </artwork></figure> 431 431 <t anchor="rule.token.separators"> … … 1019 1019 1020 1020 <section title="HTTP Message" anchor="http.message"> 1021 1022 <section title="Message Types" anchor="message.types"> 1023 <x:anchor-alias value="generic-message"/> 1024 <x:anchor-alias value="HTTP-message"/> 1025 <x:anchor-alias value="start-line"/> 1026 <t> 1027 HTTP messages consist of requests from client to server and responses 1028 from server to client. 1021 <x:anchor-alias value="generic-message"/> 1022 <x:anchor-alias value="message.types"/> 1023 <x:anchor-alias value="HTTP-message"/> 1024 <x:anchor-alias value="start-line"/> 1025 <iref item="header section"/> 1026 <iref item="headers"/> 1027 <iref item="header field"/> 1028 <t> 1029 All HTTP/1.1 messages consist of a start-line followed by a sequence of 1030 characters in a format similar to the Internet Message Format 1031 <xref target="RFC5322"/>: zero or more header fields (collectively 1032 referred to as the "headers" or the "header section"), an empty line 1033 indicating the end of the header section, and an optional message-body. 1034 </t> 1035 <t> 1036 An HTTP message can either be a request from client to server or a 1037 response from server to client. Syntactically, the two types of message 1038 differ only in the start-line, which is either a Request-Line (for requests) 1039 or a Status-Line (for responses), and in the algorithm for determining 1040 the length of the message-body (<xref target="message.length"/>). 1041 In theory, a client could receive requests and a server could receive 1042 responses, distinguishing them by their different start-line formats, 1043 but in practice servers are implemented to only expect a request 1044 (a response is interpreted as an unknown or invalid request method) 1045 and clients are implemented to only expect a response. 1029 1046 </t> 1030 1047 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-message"/> 1031 <x:ref>HTTP-message</x:ref> = <x:ref>Request</x:ref> / <x:ref>Response</x:ref> ; HTTP/1.1 messages 1032 </artwork></figure> 1033 <t> 1034 Request (<xref target="request"/>) and Response (<xref target="response"/>) messages use the generic 1035 message format of <xref target="RFC5322"/> for transferring entities (the payload 1036 of the message). Both types of message consist of a start-line, zero 1037 or more header fields (also known as "headers"), an empty line (i.e., 1038 a line with nothing preceding the CRLF) indicating the end of the 1039 header fields, and possibly a message-body. 1040 </t> 1041 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="generic-message"/><iref primary="true" item="Grammar" subitem="start-line"/> 1042 <x:ref>generic-message</x:ref> = <x:ref>start-line</x:ref> 1043 *( <x:ref>message-header</x:ref> <x:ref>CRLF</x:ref> ) 1048 <x:ref>HTTP-message</x:ref> = <x:ref>start-line</x:ref> 1049 *( <x:ref>header-field</x:ref> <x:ref>CRLF</x:ref> ) 1044 1050 <x:ref>CRLF</x:ref> 1045 1051 [ <x:ref>message-body</x:ref> ] 1046 1052 <x:ref>start-line</x:ref> = <x:ref>Request-Line</x:ref> / <x:ref>Status-Line</x:ref> 1047 1053 </artwork></figure> 1048 <t>1049 In the interest of robustness, servers &SHOULD; ignore any empty1050 line(s) received where a Request-Line is expected. In other words, if1051 the server is reading the protocol stream at the beginning of a1052 message and receives a CRLF first, it should ignore the CRLF.1053 </t>1054 <t>1055 Certain buggy HTTP/1.0 client implementations generate extra CRLF's1056 after a POST request. To restate what is explicitly forbidden by the1057 BNF, an HTTP/1.1 client &MUST-NOT; preface or follow a request with an1058 extra CRLF.1059 </t>1060 1054 <t> 1061 1055 Whitespace (WSP) &MUST-NOT; be sent between the start-line and the first … … 1067 1061 with a 400 (Bad Request) response. 1068 1062 </t> 1069 </section> 1070 1071 <section title="Message Headers" anchor="message.headers"> 1063 1064 <section title="Message Parsing Robustness" anchor="message.robustness"> 1065 <t> 1066 In the interest of robustness, servers &SHOULD; ignore at least one 1067 empty line received where a Request-Line is expected. In other words, if 1068 the server is reading the protocol stream at the beginning of a 1069 message and receives a CRLF first, it should ignore the CRLF. 1070 </t> 1071 <t> 1072 Some old HTTP/1.0 client implementations generate an extra CRLF 1073 after a POST request as a lame workaround for some early server 1074 applications that failed to read message-body content that was 1075 not terminated by a line-ending. An HTTP/1.1 client &MUST-NOT; 1076 preface or follow a request with an extra CRLF. If terminating 1077 the request message-body with a line-ending is desired, then the 1078 client &MUST; include the terminating CRLF octets as part of the 1079 message-body length. 1080 </t> 1081 <t> 1082 The normal procedure for parsing an HTTP message is to read the 1083 start-line into a structure, read each header field into a hash 1084 table by field name until the empty line, and then use the parsed 1085 data to determine if a message-body is expected. If a message-body 1086 has been indicated, then it is read as a stream until an amount 1087 of OCTETs equal to the message-length is read or the connection 1088 is closed. Care must be taken to parse an HTTP message as a sequence 1089 of OCTETs in an encoding that is a superset of US-ASCII. Attempting 1090 to parse HTTP as a stream of Unicode characters in a character encoding 1091 like UTF-16 may introduce security flaws due to the differing ways 1092 that such parsers interpret invalid characters. 1093 </t> 1094 </section> 1095 1096 <section title="Header Fields" anchor="header.fields"> 1097 <x:anchor-alias value="header-field"/> 1072 1098 <x:anchor-alias value="field-content"/> 1073 1099 <x:anchor-alias value="field-name"/> 1074 1100 <x:anchor-alias value="field-value"/> 1075 <x:anchor-alias value="message-header"/> 1076 <t> 1077 HTTP header fields follow the same general format as Internet messages in 1078 <xref target="RFC5322" x:fmt="of" x:sec="2.1"/>. Each header field consists 1079 of a name followed by a colon (":"), optional whitespace, and the field 1080 value. Field names are case-insensitive. 1081 </t> 1082 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="message-header"/><iref primary="true" item="Grammar" subitem="field-name"/><iref primary="true" item="Grammar" subitem="field-value"/><iref primary="true" item="Grammar" subitem="field-content"/> 1083 <x:ref>message-header</x:ref> = <x:ref>field-name</x:ref> ":" OWS [ <x:ref>field-value</x:ref> ] OWS 1101 <x:anchor-alias value="OWS"/> 1102 <t> 1103 Each HTTP header field consists of a case-insensitive field name 1104 followed by a colon (":"), optional whitespace, and the field value. 1105 </t> 1106 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="header-field"/><iref primary="true" item="Grammar" subitem="field-name"/><iref primary="true" item="Grammar" subitem="field-value"/><iref primary="true" item="Grammar" subitem="field-content"/> 1107 <x:ref>header-field</x:ref> = <x:ref>field-name</x:ref> ":" OWS [ <x:ref>field-value</x:ref> ] OWS 1084 1108 <x:ref>field-name</x:ref> = <x:ref>token</x:ref> 1085 1109 <x:ref>field-value</x:ref> = *( <x:ref>field-content</x:ref> / <x:ref>OWS</x:ref> ) … … 1087 1111 </artwork></figure> 1088 1112 <t> 1089 Historically, HTTP has allowed field-content with text in the ISO-8859-1 1090 <xref target="ISO-8859-1"/> character encoding (allowing other character sets 1091 through use of <xref target="RFC2047"/> encoding). In practice, most HTTP 1092 header field-values use only a subset of the US-ASCII charset 1093 <xref target="USASCII"/>. Newly defined header fields &SHOULD; constrain 1094 their field-values to US-ASCII characters. Recipients &SHOULD; treat other 1095 (obs-text) octets in field-content as opaque data. 1096 </t> 1097 <t> 1098 No whitespace is allowed between the header field-name and colon. For 1113 No whitespace is allowed between the header field name and colon. For 1099 1114 security reasons, any request message received containing such whitespace 1100 &MUST; be rejected with a response code of 400 (Bad Request) and any such 1101 whitespace in a response message &MUST; be removed. 1102 </t> 1103 <t> 1104 The field value &MAY; be preceded by optional whitespace; a single SP is 1105 preferred. The field-value does not include any leading or trailing white 1115 &MUST; be rejected with a response code of 400 (Bad Request). A proxy 1116 &MUST; remove any such whitespace from a response message before 1117 forwarding the message downstream. 1118 </t> 1119 <t> 1120 A field value &MAY; be preceded by optional whitespace (OWS); a single SP is 1121 preferred. The field value does not include any leading or trailing white 1106 1122 space: OWS occurring before the first non-whitespace character of the 1107 field -value or after the last non-whitespace character of the field-value1108 is ignored and & MAY; be removed without changing the meaning of the header1123 field value or after the last non-whitespace character of the field value 1124 is ignored and &SHOULD; be removed without changing the meaning of the header 1109 1125 field. 1110 1126 </t> 1127 <t> 1128 The order in which header fields with differing field names are 1129 received is not significant. However, it is "good practice" to send 1130 header fields that contain control data first, such as Host on 1131 requests and Date on responses, so that implementations can decide 1132 when not to handle a message as early as possible. A server &MUST; 1133 wait until the entire header section is received before interpreting 1134 a request message, since later header fields might include conditionals, 1135 authentication credentials, or deliberately misleading duplicate 1136 header fields that would impact request processing. 1137 </t> 1138 <t> 1139 Multiple header fields with the same field name &MAY; be 1140 sent in a message if and only if the entire field value for that 1141 header field is defined as a comma-separated list [i.e., #(values)]. 1142 Multiple header fields with the same field name can be combined into 1143 one "field-name: field-value" pair, without changing the semantics of the 1144 message, by appending each subsequent field value to the combined 1145 field value in order, separated by a comma. The order in which 1146 header fields with the same field name are received is therefore 1147 significant to the interpretation of the combined field value; 1148 a proxy &MUST-NOT; change the order of these field values when 1149 forwarding a message. 1150 </t> 1151 <x:note> 1152 <t> 1153 <x:h>Note:</x:h> the "Set-Cookie" header as implemented in 1154 practice (as opposed to how it is specified in <xref target="RFC2109"/>) 1155 can occur multiple times, but does not use the list syntax, and thus cannot 1156 be combined into a single line. (See Appendix A.2.3 of <xref target="Kri2001"/> 1157 for details.) Also note that the Set-Cookie2 header specified in 1158 <xref target="RFC2965"/> does not share this problem. 1159 </t> 1160 </x:note> 1111 1161 <t> 1112 1162 Historically, HTTP header field values could be extended over multiple … … 1122 1172 or forwarding the message downstream. 1123 1173 </t> 1174 <t> 1175 Historically, HTTP has allowed field content with text in the ISO-8859-1 1176 <xref target="ISO-8859-1"/> character encoding and supported other 1177 character sets only through use of <xref target="RFC2047"/> encoding. 1178 In practice, most HTTP header field values use only a subset of the 1179 US-ASCII character encoding <xref target="USASCII"/>. Newly defined 1180 header fields &SHOULD; limit their field values to US-ASCII characters. 1181 Recipients &SHOULD; treat other (obs-text) octets in field content as 1182 opaque data. 1183 </t> 1124 1184 <t anchor="rule.comment"> 1125 1185 <x:anchor-alias value="comment"/> … … 1128 1188 the comment text with parentheses. Comments are only allowed in 1129 1189 fields containing "comment" as part of their field value definition. 1130 In all other fields, parentheses are considered part of the field1131 value.1132 1190 </t> 1133 1191 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="comment"/><iref primary="true" item="Grammar" subitem="ctext"/> … … 1136 1194 ; <x:ref>OWS</x:ref> / <<x:ref>VCHAR</x:ref> except "(", ")", and "\"> / <x:ref>obs-text</x:ref> 1137 1195 </artwork></figure> 1138 <t>1139 The order in which header fields with differing field names are1140 received is not significant. However, it is "good practice" to send1141 general-header fields first, followed by request-header or response-header1142 fields, and ending with the entity-header fields.1143 </t>1144 <t>1145 Multiple message-header fields with the same field-name &MAY; be1146 present in a message if and only if the entire field-value for that1147 header field is defined as a comma-separated list [i.e., #(values)].1148 It &MUST; be possible to combine the multiple header fields into one1149 "field-name: field-value" pair, without changing the semantics of the1150 message, by appending each subsequent field-value to the first, each1151 separated by a comma. The order in which header fields with the same1152 field-name are received is therefore significant to the1153 interpretation of the combined field value, and thus a proxy &MUST-NOT;1154 change the order of these field values when a message is forwarded.1155 </t>1156 <x:note>1157 <t>1158 <x:h>Note:</x:h> the "Set-Cookie" header as implemented in1159 practice (as opposed to how it is specified in <xref target="RFC2109"/>)1160 can occur multiple times, but does not use the list syntax, and thus cannot1161 be combined into a single line. (See Appendix A.2.3 of <xref target="Kri2001"/>1162 for details.) Also note that the Set-Cookie2 header specified in1163 <xref target="RFC2965"/> does not share this problem.1164 </t>1165 </x:note>1166 1196 1167 1197 </section> … … 1194 1224 The presence of a message-body in a request is signaled by the 1195 1225 inclusion of a Content-Length or Transfer-Encoding header field in 1196 the request's message-headers.1226 the request's header fields. 1197 1227 When a request message contains both a message-body of non-zero 1198 1228 length and a method that does not define any semantics for that … … 2371 2401 2372 2402 2373 <section title="Header Field Definitions" anchor="header.field s">2403 <section title="Header Field Definitions" anchor="header.field.definitions"> 2374 2404 <t> 2375 2405 This section defines the syntax and semantics of HTTP/1.1 header fields … … 4059 4089 </t> 4060 4090 <t> 4061 The line terminator for message-header fields is the sequence CRLF.4091 The line terminator for header fields is the sequence CRLF. 4062 4092 However, we recommend that applications, when parsing such headers, 4063 4093 recognize a single LF as a line terminator and ignore the leading CR. … … 4297 4327 <t> 4298 4328 Require that invalid whitespace around field-names be rejected. 4299 (<xref target=" message.headers"/>)4329 (<xref target="header.fields"/>) 4300 4330 </t> 4301 4331 <t> … … 4387 4417 <x:ref>HTTP-Version</x:ref> = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT 4388 4418 <x:ref>HTTP-date</x:ref> = rfc1123-date / obs-date 4389 <x:ref>HTTP-message</x:ref> = Request / Response 4419 <x:ref>HTTP-message</x:ref> = start-line *( header-field CRLF ) CRLF [ 4420 message-body ] 4390 4421 <x:ref>Host</x:ref> = "Host:" OWS Host-v 4391 4422 <x:ref>Host-v</x:ref> = uri-host [ ":" port ] … … 4475 4506 <x:ref>general-header</x:ref> = Cache-Control / Connection / Date / Pragma / Trailer 4476 4507 / Transfer-Encoding / Upgrade / Via / Warning 4477 <x:ref>generic-message</x:ref> = start-line *( message-header CRLF ) CRLF [4478 message-body ]4479 4508 4480 4509 <x:ref>hour</x:ref> = 2DIGIT … … 4486 4515 <x:ref>message-body</x:ref> = entity-body / 4487 4516 <entity-body encoded as per Transfer-Encoding> 4488 <x:ref> message-header</x:ref> = field-name ":" OWS [ field-value ] OWS4517 <x:ref>header-field</x:ref> = field-name ":" OWS [ field-value ] OWS 4489 4518 <x:ref>minute</x:ref> = 2DIGIT 4490 4519 <x:ref>month</x:ref> = %x4A.61.6E ; Jan -
draft-ietf-httpbis/latest/p2-semantics.html
r632 r647 471 471 <tr> 472 472 <td class="header left"></td> 473 <td class="header right">July 2 7, 2009</td>473 <td class="header right">July 28, 2009</td> 474 474 </tr> 475 475 </table> … … 1544 1544 </p> 1545 1545 </div> 1546 <p id="rfc.section.9.4.p.6">There are circumstances in which a fragment identifier in a Location UR Lwould not be appropriate: </p>1546 <p id="rfc.section.9.4.p.6">There are circumstances in which a fragment identifier in a Location URI would not be appropriate: </p> 1547 1547 <ul> 1548 <li>With a 201 Created response, because in this usage the Location header specifies the UR Lfor the entire created resource.</li>1548 <li>With a 201 Created response, because in this usage the Location header specifies the URI for the entire created resource.</li> 1549 1549 <li>With a 300 Multiple Choices, since the choice decision is intended to be made on resource characteristics and not fragment 1550 1550 characteristics. -
draft-ietf-httpbis/latest/p3-payload.html
r628 r647 478 478 <tr> 479 479 <td class="header left"></td> 480 <td class="header right">July 2 7, 2009</td>480 <td class="header right">July 28, 2009</td> 481 481 </tr> 482 482 </table> … … 655 655 </pre><h3 id="rfc.section.1.2.2"><a href="#rfc.section.1.2.2">1.2.2</a> <a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3> 656 656 <p id="rfc.section.1.2.2.p.1">The ABNF rules below are defined in other parts:</p> 657 <div id="rfc.figure.u.2"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2. 3</a>>657 <div id="rfc.figure.u.2"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.6</a>> 658 658 <a href="#abnf.dependencies" class="smpl">Content-Length</a> = <Content-Length, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.content-length" title="Content-Length">Section 8.2</a>> 659 <a href="#abnf.dependencies" class="smpl"> message-header</a> = <message-header, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#message.headers" title="Message Headers">Section 3.2</a>>660 <a href="#abnf.dependencies" class="smpl">partial-URI</a> = <partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2. 3</a>>659 <a href="#abnf.dependencies" class="smpl">header-field</a> = <header-field, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>> 660 <a href="#abnf.dependencies" class="smpl">partial-URI</a> = <partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.6</a>> 661 661 <a href="#abnf.dependencies" class="smpl">qvalue</a> = <qvalue, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#quality.values" title="Quality Values">Section 6.4</a>> 662 662 </pre><div id="rfc.figure.u.3"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">Last-Modified</a> = <Last-Modified, defined in <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 6.6</a>> … … 847 847 / <a href="#entity.header.fields" class="smpl">extension-header</a> 848 848 849 <a href="#entity.header.fields" class="smpl">extension-header</a> = <a href="#abnf.dependencies" class="smpl"> message-header</a>849 <a href="#entity.header.fields" class="smpl">extension-header</a> = <a href="#abnf.dependencies" class="smpl">header-field</a> 850 850 </pre><p id="rfc.section.3.1.p.3">The extension-header mechanism allows additional entity-header fields to be defined without changing the protocol, but these 851 851 fields cannot be assumed to be recognizable by the recipient. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by the recipient and <em class="bcp14">MUST</em> be forwarded by transparent proxies. … … 1788 1788 / Content-Location / Content-MD5 / Content-Range / Content-Type / 1789 1789 Expires / Last-Modified / extension-header 1790 <a href="#entity.header.fields" class="smpl">extension-header</a> = message-header1790 <a href="#entity.header.fields" class="smpl">extension-header</a> = header-field 1791 1791 1792 1792 <a href="#content-disposition" class="smpl">filename-parm</a> = "filename=" quoted-string … … 1798 1798 ";" OWS parameter ) 1799 1799 <a href="#media.types" class="smpl">media-type</a> = type "/" subtype *( OWS ";" OWS parameter ) 1800 <a href="#abnf.dependencies" class="smpl"> message-header</a> = <message-header, defined in [Part1], Section 3.2>1800 <a href="#abnf.dependencies" class="smpl">header-field</a> = <header-field, defined in [Part1], Section 3.2> 1801 1801 1802 1802 <a href="#rule.parameter" class="smpl">parameter</a> = attribute "=" value … … 2061 2061 <li class="indline1"><em>Section 1.2</em> <a class="iref" href="#rfc.xref.Part1.1">1.2</a></li> 2062 2062 <li class="indline1"><em>Section 1.2.2</em> <a class="iref" href="#rfc.xref.Part1.2">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.2.1</a></li> 2063 <li class="indline1"><em>Section 2. 3</em> <a class="iref" href="#rfc.xref.Part1.6">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.9">1.2.2</a></li>2063 <li class="indline1"><em>Section 2.6</em> <a class="iref" href="#rfc.xref.Part1.6">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.9">1.2.2</a></li> 2064 2064 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part1.8">1.2.2</a></li> 2065 2065 <li class="indline1"><em>Section 3.3</em> <a class="iref" href="#rfc.xref.Part1.12">3.2</a></li> -
draft-ietf-httpbis/latest/p3-payload.xml
r628 r647 28 28 <!ENTITY message-body "<xref target='Part1' x:rel='#message.body' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 29 29 <!ENTITY message-length "<xref target='Part1' x:rel='#message.length' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 30 <!ENTITY message-headers "<xref target='Part1' x:rel='#message.headers' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">30 <!ENTITY header-fields "<xref target='Part1' x:rel='#header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 31 31 <!ENTITY multipart-byteranges "<xref target='Part5' x:rel='#internet.media.type.multipart.byteranges' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 32 32 <!ENTITY full-date "<xref target='Part1' x:rel='#date.time.formats.full.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 300 300 <x:anchor-alias value="Expires"/> 301 301 <x:anchor-alias value="Last-Modified"/> 302 <x:anchor-alias value=" message-header"/>302 <x:anchor-alias value="header-field"/> 303 303 <x:anchor-alias value="partial-URI"/> 304 304 <x:anchor-alias value="qvalue"/> … … 309 309 <x:ref>absolute-URI</x:ref> = <absolute-URI, defined in &uri;> 310 310 <x:ref>Content-Length</x:ref> = <Content-Length, defined in &header-content-length;> 311 <x:ref> message-header</x:ref> = <message-header, defined in &message-headers;>311 <x:ref>header-field</x:ref> = <header-field, defined in &header-fields;> 312 312 <x:ref>partial-URI</x:ref> = <partial-URI, defined in &uri;> 313 313 <x:ref>qvalue</x:ref> = <qvalue, defined in &qvalue;> … … 679 679 / <x:ref>extension-header</x:ref> 680 680 681 <x:ref>extension-header</x:ref> = <x:ref> message-header</x:ref>681 <x:ref>extension-header</x:ref> = <x:ref>header-field</x:ref> 682 682 </artwork></figure> 683 683 <t> … … 2729 2729 / Content-Location / Content-MD5 / Content-Range / Content-Type / 2730 2730 Expires / Last-Modified / extension-header 2731 <x:ref>extension-header</x:ref> = message-header2731 <x:ref>extension-header</x:ref> = header-field 2732 2732 2733 2733 <x:ref>filename-parm</x:ref> = "filename=" quoted-string … … 2739 2739 ";" OWS parameter ) 2740 2740 <x:ref>media-type</x:ref> = type "/" subtype *( OWS ";" OWS parameter ) 2741 <x:ref> message-header</x:ref> = <message-header, defined in [Part1], Section 3.2>2741 <x:ref>header-field</x:ref> = <header-field, defined in [Part1], Section 3.2> 2742 2742 2743 2743 <x:ref>parameter</x:ref> = attribute "=" value -
draft-ietf-httpbis/latest/p5-range.html
r643 r647 1148 1148 <a href="#header.content-range" class="smpl">other-content-range-spec</a> = other-range-unit SP other-range-resp-spec 1149 1149 <a href="#header.content-range" class="smpl">other-range-resp-spec</a> = *CHAR 1150 <a href="#range.retrieval.requests" class="smpl">other-range-set</a> = 1*CHAR 1150 1151 <a href="#range.units" class="smpl">other-range-unit</a> = token 1151 <a href="#range.retrieval.requests" class="smpl">other-ranges-specifier</a> = 1*CHAR1152 <a href="#range.retrieval.requests" class="smpl">other-ranges-specifier</a> = other-range-unit "=" other-range-set 1152 1153 1153 1154 <a href="#range.units" class="smpl">range-unit</a> = bytes-unit / other-range-unit -
draft-ietf-httpbis/latest/p6-cache.html
r628 r647 473 473 <tr> 474 474 <td class="header left"></td> 475 <td class="header right">July 2 7, 2009</td>475 <td class="header right">July 28, 2009</td> 476 476 </tr> 477 477 </table> … … 692 692 </pre><h3 id="rfc.section.1.4.2"><a href="#rfc.section.1.4.2">1.4.2</a> <a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3> 693 693 <p id="rfc.section.1.4.2.p.1">The ABNF rules below are defined in other parts:</p> 694 <div id="rfc.figure.u.2"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">field-name</a> = <field-name, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html# message.headers" title="Message Headers">Section 3.2</a>>694 <div id="rfc.figure.u.2"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">field-name</a> = <field-name, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>> 695 695 <a href="#abnf.dependencies" class="smpl">HTTP-date</a> = <HTTP-date, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a>> 696 <a href="#abnf.dependencies" class="smpl">port</a> = <port, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2. 3</a>>696 <a href="#abnf.dependencies" class="smpl">port</a> = <port, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.6</a>> 697 697 <a href="#abnf.dependencies" class="smpl">pseudonym</a> = <pseudonym, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.via" title="Via">Section 8.9</a>> 698 <a href="#abnf.dependencies" class="smpl">uri-host</a> = <uri-host, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2. 3</a>>698 <a href="#abnf.dependencies" class="smpl">uri-host</a> = <uri-host, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.6</a>> 699 699 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="caching.overview" href="#caching.overview">Cache Operation</a></h1> 700 700 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="response.cacheability" href="#response.cacheability">Response Cacheability</a></h2> … … 923 923 <p id="rfc.section.2.6.p.2">The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first 924 924 request can be transformed to the selecting request-headers in the second request by adding or removing linear white space <span class="comment" id="rfc.comment.9">[<a href="#rfc.comment.9" class="smpl">rfc.comment.9</a>: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field 925 name following the rules about message headers in <a href="p1-messaging.html#message.headers" title="Message Headers">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.925 name following the rules about header fields in <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 926 926 </p> 927 927 <p id="rfc.section.2.6.p.3">If a header field is absent from a request, it can only match another request if it is also absent there.</p> … … 1868 1868 <li class="indline1"><em>Section 1.2</em> <a class="iref" href="#rfc.xref.Part1.1">1.4</a></li> 1869 1869 <li class="indline1"><em>Section 1.2.2</em> <a class="iref" href="#rfc.xref.Part1.2">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.4.1</a></li> 1870 <li class="indline1"><em>Section 2. 3</em> <a class="iref" href="#rfc.xref.Part1.8">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.4.2</a></li>1870 <li class="indline1"><em>Section 2.6</em> <a class="iref" href="#rfc.xref.Part1.8">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.4.2</a></li> 1871 1871 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part1.6">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.12">2.6</a></li> 1872 1872 <li class="indline1"><em>Section 6.1</em> <a class="iref" href="#rfc.xref.Part1.7">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.13">3.3</a></li> -
draft-ietf-httpbis/latest/p6-cache.xml
r628 r647 29 29 <!ENTITY header-via "<xref target='Part1' x:rel='#header.via' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 30 30 <!ENTITY header-last-modified "<xref target='Part4' x:rel='#header.last-modified' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 31 <!ENTITY message-headers "<xref target='Part1' x:rel='#message.headers' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">31 <!ENTITY header-fields "<xref target='Part1' x:rel='#header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 32 32 <!ENTITY message-length "<xref target='Part1' x:rel='#message.length' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 33 33 <!ENTITY safe-methods "<xref target='Part2' x:rel='#safe.methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 406 406 </t> 407 407 <figure><!--Part1--><artwork type="abnf2616"> 408 <x:ref>field-name</x:ref> = <field-name, defined in & message-headers;>408 <x:ref>field-name</x:ref> = <field-name, defined in &header-fields;> 409 409 <x:ref>HTTP-date</x:ref> = <HTTP-date, defined in &full-date;> 410 410 <x:ref>port</x:ref> = <port, defined in &uri;> … … 823 823 <cref>[ref]</cref> at places where this is allowed by the corresponding ABNF, and/or 824 824 combining multiple message-header fields with the same field name following the rules 825 about message headers in &message-headers;.825 about header fields in &header-fields;. 826 826 </t> 827 827 <t>
Note: See TracChangeset
for help on using the changeset viewer.