Changeset 1642 for draft-ietf-httpbis/latest
- Timestamp:
- 30/03/12 14:52:26 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 4 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1641 r1642 822 822 <a href="#core.rules" class="smpl">quoted-string</a> = <quoted-string, 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#field.components" title="Field value components">Section 3.2.4</a>> 823 823 <a href="#core.rules" class="smpl">token</a> = <token, 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#field.components" title="Field value components">Section 3.2.4</a>> 824 <a href="#core.rules" class="smpl">word</a> = <word, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>> 824 825 </pre><h3 id="rfc.section.1.3.2"><a href="#rfc.section.1.3.2">1.3.2</a> <a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3> 825 826 <p id="rfc.section.1.3.2.p.1">The ABNF rules below are defined in other parts:</p> 826 <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.1 1"><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.7</a>>827 <a href="#abnf.dependencies" class="smpl">comment</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.1 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>>828 <a href="#abnf.dependencies" class="smpl">partial-URI</a> = <partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.1 3"><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.7</a>>829 <a href="#abnf.dependencies" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.1 4"><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.7</a>>827 <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.12"><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.7</a>> 828 <a href="#abnf.dependencies" class="smpl">comment</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>> 829 <a href="#abnf.dependencies" class="smpl">partial-URI</a> = <partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.14"><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.7</a>> 830 <a href="#abnf.dependencies" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.15"><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.7</a>> 830 831 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="methods" href="#methods">Methods</a></h1> 831 <p id="rfc.section.2.p.1">The method token indicates the request method to be performed on the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.1 5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive.832 <p id="rfc.section.2.p.1">The method token indicates the request method to be performed on the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive. 832 833 </p> 833 834 <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1"></span> <a href="#methods" class="smpl">method</a> = <a href="#core.rules" class="smpl">token</a> … … 880 881 to a single application, so that this is clear. 881 882 </p> 882 <p id="rfc.section.2.2.1.p.3">Due to the parsing rules defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.1 6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, definitions of HTTP methods cannot prohibit the presence of a message body on either the request or the response message883 <p id="rfc.section.2.2.1.p.3">Due to the parsing rules defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, definitions of HTTP methods cannot prohibit the presence of a message body on either the request or the response message 883 884 (with responses to HEAD requests being the single exception). Definitions of new methods cannot change this rule, but they 884 885 can specify that only zero-length bodies (as opposed to absent bodies) are allowed. … … 900 901 to HTTP might use the OPTIONS body to make more detailed queries on the server. 901 902 </p> 902 <p id="rfc.section.2.3.1.p.4">If the request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.1 7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource.903 <p id="rfc.section.2.3.1.p.4">If the request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource. 903 904 Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" 904 905 type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be … … 1063 1064 </p> 1064 1065 <p id="rfc.section.2.3.7.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing 1065 or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.1 8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the1066 or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the 1066 1067 client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an 1067 1068 infinite loop. 1068 1069 </p> 1069 <p id="rfc.section.2.3.7.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 7.3.1</a> of <a href="#Part1" id="rfc.xref.Part1. 19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable.1070 <p id="rfc.section.2.3.7.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 7.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable. 1070 1071 </p> 1071 1072 <div id="rfc.iref.c.2"></div> … … 1075 1076 its behavior to blind forwarding of packets until the connection is closed. 1076 1077 </p> 1077 <p id="rfc.section.2.3.8.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.2 0"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon.1078 <p id="rfc.section.2.3.8.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon. 1078 1079 For example, 1079 1080 </p> … … 1111 1112 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="header.fields" href="#header.fields">Header Fields</a></h1> 1112 1113 <p id="rfc.section.3.p.1">Header fields are key value pairs that can be used to communicate data about the message, its payload, the target resource, 1113 or about the connection itself (i.e., control data). See <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.2 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for a general definition of their syntax.1114 or about the connection itself (i.e., control data). See <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for a general definition of their syntax. 1114 1115 </p> 1115 1116 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="considerations.for.creating.header.fields" href="#considerations.for.creating.header.fields">Considerations for Creating Header Fields</a></h2> … … 1119 1120 with "X-" if they are to be registered (either immediately or in the future). 1120 1121 </p> 1121 <p id="rfc.section.3.1.p.3">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.3"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extension defined in <a href="p1-messaging.html#abnf.extension" title="ABNF list extension: #rule">Section 3.2.5</a> of <a href="#Part1" id="rfc.xref.Part1.2 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters1122 <p id="rfc.section.3.1.p.3">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.3"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extension defined in <a href="p1-messaging.html#abnf.extension" title="ABNF list extension: #rule">Section 3.2.5</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters 1122 1123 can use an encoding such as the one defined in <a href="#RFC5987" id="rfc.xref.RFC5987.1"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>. 1123 1124 </p> 1124 1125 <p id="rfc.section.3.1.p.4">Because commas (",") are used as a generic delimiter between field-values, they need to be treated with care if they are allowed 1125 1126 in the field-value's payload. Typically, components that might contain a comma are protected with double-quotes using the 1126 quoted-string ABNF production (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a> of <a href="#Part1" id="rfc.xref.Part1.2 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).1127 quoted-string ABNF production (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1127 1128 </p> 1128 1129 <p id="rfc.section.3.1.p.5">For example, a textual date and a URI (either of which might contain a comma) could be safely carried in field-values like … … 1142 1143 <ul> 1143 1144 <li> 1144 <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.2 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).1145 <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1145 1146 </p> 1146 1147 <p>If it does not use the list syntax, document how to treat messages where the header field occurs multiple times (a sensible … … 1158 1159 </li> 1159 1160 <li> 1160 <p>Whether it is appropriate to list the field-name in the Connection header (i.e., if the header is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.2 5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).1161 <p>Whether it is appropriate to list the field-name in the Connection header (i.e., if the header is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1161 1162 </p> 1162 1163 </li> … … 1169 1170 </li> 1170 1171 <li> 1171 <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> of <a href="#Part1" id="rfc.xref.Part1.2 6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).1172 <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1172 1173 </p> 1173 1174 </li> … … 1220 1221 <tr> 1221 1222 <td class="left">Host</td> 1222 <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 5.4</a> of <a href="#Part1" id="rfc.xref.Part1.2 7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>1223 <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 5.4</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td> 1223 1224 </tr> 1224 1225 <tr> … … 1260 1261 <tr> 1261 1262 <td class="left">TE</td> 1262 <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.2 8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>1263 <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td> 1263 1264 </tr> 1264 1265 <tr> … … 1271 1272 <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h2> 1272 1273 <p id="rfc.section.3.3.p.1">The response header fields allow the server to pass additional information about the response which cannot be placed in the 1273 status-line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1. 29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).1274 status-line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1274 1275 </p> 1275 1276 <div id="rfc.table.u.2"> … … 1613 1614 <p id="rfc.section.4.3.1.p.1">The client <em class="bcp14">SHOULD</em> continue with its request. This interim response is used to inform the client that the initial part of the request has been 1614 1615 received and has not yet been rejected by the server. The client <em class="bcp14">SHOULD</em> continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The 1615 server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.4.3</a> of <a href="#Part1" id="rfc.xref.Part1.3 0"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code.1616 server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.4.3</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code. 1616 1617 </p> 1617 1618 <div id="rfc.iref.22"></div> 1618 1619 <div id="rfc.iref.s.4"></div> 1619 1620 <h3 id="rfc.section.4.3.2"><a href="#rfc.section.4.3.2">4.3.2</a> <a id="status.101" href="#status.101">101 Switching Protocols</a></h3> 1620 <p id="rfc.section.4.3.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.5</a> of <a href="#Part1" id="rfc.xref.Part1.3 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined1621 <p id="rfc.section.4.3.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.5</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined 1621 1622 by the response's Upgrade header field immediately after the empty line which terminates the 101 response. 1622 1623 </p> … … 1671 1672 <div id="rfc.iref.s.8"></div> 1672 1673 <h3 id="rfc.section.4.4.4"><a href="#rfc.section.4.4.4">4.4.4</a> <a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3> 1673 <p id="rfc.section.4.4.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.3</a> of <a href="#Part1" id="rfc.xref.Part1.3 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Note that the behavior of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).1674 <p id="rfc.section.4.4.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.3</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Note that the behavior of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1674 1675 </p> 1675 1676 <p id="rfc.section.4.4.4.p.2">This status code is only appropriate when the response status code would have been 200 (OK) otherwise. When the status code … … 1706 1707 another input action. 1707 1708 </p> 1708 <p id="rfc.section.4.4.6.p.2">The message body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.3 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.1709 <p id="rfc.section.4.4.6.p.2">The message body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 1709 1710 </p> 1710 1711 <h2 id="rfc.section.4.5"><a href="#rfc.section.4.5">4.5</a> <a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2> … … 1966 1967 <div id="rfc.iref.s.32"></div> 1967 1968 <h3 id="rfc.section.4.6.15"><a href="#rfc.section.4.6.15">4.6.15</a> <a id="status.426" href="#status.426">426 Upgrade Required</a></h3> 1968 <p id="rfc.section.4.6.15.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an Upgrade header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.5</a> of <a href="#Part1" id="rfc.xref.Part1.3 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols.1969 <p id="rfc.section.4.6.15.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an Upgrade header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.5</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols. 1969 1970 </p> 1970 1971 <div id="rfc.figure.u.7"></div> … … 2027 2028 <p id="rfc.section.4.7.6.p.1">The server does not support, or refuses to support, the protocol version that was used in the request message. The server 2028 2029 is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described 2029 in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.3 5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server.2030 in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server. 2030 2031 </p> 2031 2032 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="representation" href="#representation">Representation</a></h1> … … 2034 2035 in an HTTP message, it is referred to as the payload of the message. HTTP representations are defined in <a href="#Part3" id="rfc.xref.Part3.12"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. 2035 2036 </p> 2036 <p id="rfc.section.5.p.2">A representation body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.3 6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message body by decoding any Transfer-Encoding that might have been applied2037 <p id="rfc.section.5.p.2">A representation body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.37"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message body by decoding any Transfer-Encoding that might have been applied 2037 2038 to ensure safe and proper transfer of the message. 2038 2039 </p> … … 2040 2041 <p id="rfc.section.5.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p> 2041 2042 <p id="rfc.section.5.1.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p> 2042 <p id="rfc.section.5.1.p.3">In the common case, an HTTP response is a representation of the target resource (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.3 7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following2043 <p id="rfc.section.5.1.p.3">In the common case, an HTTP response is a representation of the target resource (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.38"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following 2043 2044 rules are used (with the first applicable one being selected): 2044 2045 </p> … … 2225 2226 </p> 2226 2227 <ul class="empty"> 2227 <li>The "100-continue" expectation is defined <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.4.3</a> of <a href="#Part1" id="rfc.xref.Part1.3 8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. It does not support any expect-params.2228 <li>The "100-continue" expectation is defined <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.4.3</a> of <a href="#Part1" id="rfc.xref.Part1.39"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. It does not support any expect-params. 2228 2229 </li> 2229 2230 </ul> … … 2337 2338 <h2 id="rfc.section.7.9"><a href="#rfc.section.7.9">7.9</a> <a id="header.server" href="#header.server">Server</a></h2> 2338 2339 <p id="rfc.section.7.9.p.1">The "Server" header field contains information about the software used by the origin server to handle the request.</p> 2339 <p id="rfc.section.7.9.p.2">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 6.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1. 39"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for2340 <p id="rfc.section.7.9.p.2">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 6.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.40"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for 2340 2341 identifying the application. 2341 2342 </p> … … 2343 2344 </pre><p id="rfc.section.7.9.p.4">Example:</p> 2344 2345 <div id="rfc.figure.u.34"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 2345 </pre><p id="rfc.section.7.9.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.4 0"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).2346 </pre><p id="rfc.section.7.9.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.41"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 2346 2347 </p> 2347 2348 <div class="note" id="rfc.section.7.9.p.7"> … … 2359 2360 user agent limitations. 2360 2361 </p> 2361 <p id="rfc.section.7.10.p.3">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 6.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.4 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance2362 <p id="rfc.section.7.10.p.3">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 6.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.42"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance 2362 2363 for identifying the application. 2363 2364 </p> … … 2829 2830 </p> 2830 2831 <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> 2831 <p id="rfc.section.10.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.4 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.2832 <p id="rfc.section.10.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.43"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 2832 2833 </p> 2833 2834 <h1 id="rfc.references"><a id="rfc.section.11" href="#rfc.section.11">11.</a> References … … 3078 3079 </p> 3079 3080 <p id="rfc.section.A.p.16">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated 3080 correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.4 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 7.9</a>)3081 correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 7.9</a>) 3081 3082 </p> 3082 3083 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> … … 3176 3177 <a href="#core.rules" class="smpl">token</a> = <token, defined in [Part1], Section 3.2.4> 3177 3178 3179 word = <word, defined in [Part1], Section 3.2.4> 3180 3178 3181 <a href="#preferred.date.format" class="smpl">year</a> = 4DIGIT 3179 3182 </pre> <div id="rfc.figure.u.38"></div> … … 3189 3192 ; User-Agent defined but not used 3190 3193 ; obs-text defined but not used 3194 ; word defined but not used 3191 3195 </pre><h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="change.log" href="#change.log">Change Log (to be removed by RFC Editor before publication)</a></h1> 3192 3196 <h2 id="rfc.section.C.1"><a href="#rfc.section.C.1">C.1</a> Since RFC 2616 … … 3686 3690 </li> 3687 3691 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3688 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">1.3</a>, <a href="#rfc.xref.Part1.4">1.3.1</a>, <a href="#rfc.xref.Part1.5">1.3.1</a>, <a href="#rfc.xref.Part1.6">1.3.1</a>, <a href="#rfc.xref.Part1.7">1.3.1</a>, <a href="#rfc.xref.Part1.8">1.3.1</a>, <a href="#rfc.xref.Part1.9">1.3.1</a>, <a href="#rfc.xref.Part1.10">1.3.1</a>, <a href="#rfc.xref.Part1.11">1.3. 2</a>, <a href="#rfc.xref.Part1.12">1.3.2</a>, <a href="#rfc.xref.Part1.13">1.3.2</a>, <a href="#rfc.xref.Part1.14">1.3.2</a>, <a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.17">2.3.1</a>, <a href="#rfc.xref.Part1.18">2.3.7</a>, <a href="#rfc.xref.Part1.19">2.3.7</a>, <a href="#rfc.xref.Part1.20">2.3.8</a>, <a href="#rfc.xref.Part1.21">3</a>, <a href="#rfc.xref.Part1.22">3.1</a>, <a href="#rfc.xref.Part1.23">3.1</a>, <a href="#rfc.xref.Part1.24">3.1</a>, <a href="#rfc.xref.Part1.25">3.1</a>, <a href="#rfc.xref.Part1.26">3.1</a>, <a href="#rfc.xref.Part1.27">3.2</a>, <a href="#rfc.xref.Part1.28">3.2</a>, <a href="#rfc.xref.Part1.29">3.3</a>, <a href="#rfc.xref.Part1.30">4.3.1</a>, <a href="#rfc.xref.Part1.31">4.3.2</a>, <a href="#rfc.xref.Part1.32">4.4.4</a>, <a href="#rfc.xref.Part1.33">4.4.6</a>, <a href="#rfc.xref.Part1.34">4.6.15</a>, <a href="#rfc.xref.Part1.35">4.7.6</a>, <a href="#rfc.xref.Part1.36">5</a>, <a href="#rfc.xref.Part1.37">5.1</a>, <a href="#rfc.xref.Part1.38">7.3</a>, <a href="#rfc.xref.Part1.39">7.9</a>, <a href="#rfc.xref.Part1.40">7.9</a>, <a href="#rfc.xref.Part1.41">7.10</a>, <a href="#rfc.xref.Part1.42">10</a>, <a href="#Part1"><b>11.1</b></a>, <a href="#rfc.xref.Part1.43">A</a><ul>3692 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">1.3</a>, <a href="#rfc.xref.Part1.4">1.3.1</a>, <a href="#rfc.xref.Part1.5">1.3.1</a>, <a href="#rfc.xref.Part1.6">1.3.1</a>, <a href="#rfc.xref.Part1.7">1.3.1</a>, <a href="#rfc.xref.Part1.8">1.3.1</a>, <a href="#rfc.xref.Part1.9">1.3.1</a>, <a href="#rfc.xref.Part1.10">1.3.1</a>, <a href="#rfc.xref.Part1.11">1.3.1</a>, <a href="#rfc.xref.Part1.12">1.3.2</a>, <a href="#rfc.xref.Part1.13">1.3.2</a>, <a href="#rfc.xref.Part1.14">1.3.2</a>, <a href="#rfc.xref.Part1.15">1.3.2</a>, <a href="#rfc.xref.Part1.16">2</a>, <a href="#rfc.xref.Part1.17">2.2.1</a>, <a href="#rfc.xref.Part1.18">2.3.1</a>, <a href="#rfc.xref.Part1.19">2.3.7</a>, <a href="#rfc.xref.Part1.20">2.3.7</a>, <a href="#rfc.xref.Part1.21">2.3.8</a>, <a href="#rfc.xref.Part1.22">3</a>, <a href="#rfc.xref.Part1.23">3.1</a>, <a href="#rfc.xref.Part1.24">3.1</a>, <a href="#rfc.xref.Part1.25">3.1</a>, <a href="#rfc.xref.Part1.26">3.1</a>, <a href="#rfc.xref.Part1.27">3.1</a>, <a href="#rfc.xref.Part1.28">3.2</a>, <a href="#rfc.xref.Part1.29">3.2</a>, <a href="#rfc.xref.Part1.30">3.3</a>, <a href="#rfc.xref.Part1.31">4.3.1</a>, <a href="#rfc.xref.Part1.32">4.3.2</a>, <a href="#rfc.xref.Part1.33">4.4.4</a>, <a href="#rfc.xref.Part1.34">4.4.6</a>, <a href="#rfc.xref.Part1.35">4.6.15</a>, <a href="#rfc.xref.Part1.36">4.7.6</a>, <a href="#rfc.xref.Part1.37">5</a>, <a href="#rfc.xref.Part1.38">5.1</a>, <a href="#rfc.xref.Part1.39">7.3</a>, <a href="#rfc.xref.Part1.40">7.9</a>, <a href="#rfc.xref.Part1.41">7.9</a>, <a href="#rfc.xref.Part1.42">7.10</a>, <a href="#rfc.xref.Part1.43">10</a>, <a href="#Part1"><b>11.1</b></a>, <a href="#rfc.xref.Part1.44">A</a><ul> 3689 3693 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.3">1.3</a></li> 3690 3694 <li><em>Section 2</em> <a href="#rfc.xref.Part1.2">1.2</a></li> 3691 <li><em>Section 2.3</em> <a href="#rfc.xref.Part1.3 2">4.4.4</a></li>3692 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1.3 5">4.7.6</a></li>3693 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.1 1">1.3.2</a>, <a href="#rfc.xref.Part1.13">1.3.2</a>, <a href="#rfc.xref.Part1.14">1.3.2</a></li>3695 <li><em>Section 2.3</em> <a href="#rfc.xref.Part1.33">4.4.4</a></li> 3696 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1.36">4.7.6</a></li> 3697 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.12">1.3.2</a>, <a href="#rfc.xref.Part1.14">1.3.2</a>, <a href="#rfc.xref.Part1.15">1.3.2</a></li> 3694 3698 <li><em>Section 3.2.1</em> <a href="#rfc.xref.Part1.5">1.3.1</a>, <a href="#rfc.xref.Part1.6">1.3.1</a>, <a href="#rfc.xref.Part1.7">1.3.1</a></li> 3695 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.2 1">3</a>, <a href="#rfc.xref.Part1.24">3.1</a>, <a href="#rfc.xref.Part1.39">7.9</a>, <a href="#rfc.xref.Part1.41">7.10</a></li>3696 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part1.8">1.3.1</a>, <a href="#rfc.xref.Part1.9">1.3.1</a>, <a href="#rfc.xref.Part1.10">1.3.1</a>, <a href="#rfc.xref.Part1.1 2">1.3.2</a>, <a href="#rfc.xref.Part1.23">3.1</a></li>3697 <li><em>Section 3.2.5</em> <a href="#rfc.xref.Part1.2 2">3.1</a></li>3698 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.1 6">2.2.1</a>, <a href="#rfc.xref.Part1.33">4.4.6</a>, <a href="#rfc.xref.Part1.36">5</a></li>3699 <li><em>Section 4.1</em> <a href="#rfc.xref.Part1.2 6">3.1</a></li>3700 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.2 8">3.2</a></li>3701 <li><em>Section 5.3</em> <a href="#rfc.xref.Part1.1 7">2.3.1</a>, <a href="#rfc.xref.Part1.20">2.3.8</a></li>3702 <li><em>Section 5.4</em> <a href="#rfc.xref.Part1.2 7">3.2</a></li>3703 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.1 5">2</a>, <a href="#rfc.xref.Part1.29">3.3</a>, <a href="#rfc.xref.Part1.37">5.1</a></li>3704 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.2 5">3.1</a></li>3705 <li><em>Section 6.2</em> <a href="#rfc.xref.Part1.1 8">2.3.7</a>, <a href="#rfc.xref.Part1.40">7.9</a>, <a href="#rfc.xref.Part1.43">A</a></li>3706 <li><em>Section 6.4.3</em> <a href="#rfc.xref.Part1.3 0">4.3.1</a>, <a href="#rfc.xref.Part1.38">7.3</a></li>3707 <li><em>Section 6.5</em> <a href="#rfc.xref.Part1.3 1">4.3.2</a>, <a href="#rfc.xref.Part1.34">4.6.15</a></li>3708 <li><em>Section 7.3.1</em> <a href="#rfc.xref.Part1. 19">2.3.7</a></li>3709 <li><em>Section 9</em> <a href="#rfc.xref.Part1.4 2">10</a></li>3699 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.22">3</a>, <a href="#rfc.xref.Part1.25">3.1</a>, <a href="#rfc.xref.Part1.40">7.9</a>, <a href="#rfc.xref.Part1.42">7.10</a></li> 3700 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part1.8">1.3.1</a>, <a href="#rfc.xref.Part1.9">1.3.1</a>, <a href="#rfc.xref.Part1.10">1.3.1</a>, <a href="#rfc.xref.Part1.11">1.3.1</a>, <a href="#rfc.xref.Part1.13">1.3.2</a>, <a href="#rfc.xref.Part1.24">3.1</a></li> 3701 <li><em>Section 3.2.5</em> <a href="#rfc.xref.Part1.23">3.1</a></li> 3702 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.17">2.2.1</a>, <a href="#rfc.xref.Part1.34">4.4.6</a>, <a href="#rfc.xref.Part1.37">5</a></li> 3703 <li><em>Section 4.1</em> <a href="#rfc.xref.Part1.27">3.1</a></li> 3704 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.29">3.2</a></li> 3705 <li><em>Section 5.3</em> <a href="#rfc.xref.Part1.18">2.3.1</a>, <a href="#rfc.xref.Part1.21">2.3.8</a></li> 3706 <li><em>Section 5.4</em> <a href="#rfc.xref.Part1.28">3.2</a></li> 3707 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.16">2</a>, <a href="#rfc.xref.Part1.30">3.3</a>, <a href="#rfc.xref.Part1.38">5.1</a></li> 3708 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.26">3.1</a></li> 3709 <li><em>Section 6.2</em> <a href="#rfc.xref.Part1.19">2.3.7</a>, <a href="#rfc.xref.Part1.41">7.9</a>, <a href="#rfc.xref.Part1.44">A</a></li> 3710 <li><em>Section 6.4.3</em> <a href="#rfc.xref.Part1.31">4.3.1</a>, <a href="#rfc.xref.Part1.39">7.3</a></li> 3711 <li><em>Section 6.5</em> <a href="#rfc.xref.Part1.32">4.3.2</a>, <a href="#rfc.xref.Part1.35">4.6.15</a></li> 3712 <li><em>Section 7.3.1</em> <a href="#rfc.xref.Part1.20">2.3.7</a></li> 3713 <li><em>Section 9</em> <a href="#rfc.xref.Part1.43">10</a></li> 3710 3714 </ul> 3711 3715 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1641 r1642 317 317 318 318 <section title="Syntax Notation" anchor="notation"> 319 <x:anchor-alias value="ALPHA"/> 319 320 <x:anchor-alias value="CR"/> 320 321 <x:anchor-alias value="DIGIT"/> 321 322 <x:anchor-alias value="LF"/> 322 <x:anchor-alias value="HTAB"/> 323 <x:anchor-alias value="OCTET"/> 324 <x:anchor-alias value="SP"/> 323 325 <x:anchor-alias value="VCHAR"/> 324 <x:anchor-alias value="SP"/>325 326 <t> 326 327 This specification uses the Augmented Backus-Naur Form (ABNF) notation … … 343 344 <x:anchor-alias value="quoted-string"/> 344 345 <x:anchor-alias value="token"/> 346 <x:anchor-alias value="word"/> 345 347 <x:anchor-alias value="BWS"/> 346 348 <x:anchor-alias value="OWS"/> … … 356 358 <x:ref>quoted-string</x:ref> = <quoted-string, defined in &field-components;> 357 359 <x:ref>token</x:ref> = <token, defined in &field-components;> 360 <x:ref>word</x:ref> = <word, defined in &field-components;> 358 361 </artwork></figure> 359 362 </section> … … 363 366 <x:anchor-alias value="comment"/> 364 367 <x:anchor-alias value="partial-URI"/> 368 <x:anchor-alias value="qvalue"/> 365 369 <x:anchor-alias value="URI-reference"/> 366 370 <t> … … 4177 4181 <x:ref>token</x:ref> = <token, defined in [Part1], Section 3.2.4> 4178 4182 4183 word = <word, defined in [Part1], Section 3.2.4> 4184 4179 4185 <x:ref>year</x:ref> = 4DIGIT 4180 4186 </artwork> … … 4192 4198 ; User-Agent defined but not used 4193 4199 ; obs-text defined but not used 4200 ; word defined but not used 4194 4201 </artwork></figure></section> 4195 4202 <?ENDINC p2-semantics.abnf-appendix ?> -
draft-ietf-httpbis/latest/p3-payload.html
r1641 r1642 675 675 <p id="rfc.section.1.p.1">This part is now obsolete. Please see HTTPbis, Part 2.</p> 676 676 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="notation" href="#notation">Syntax Notation</a></h2> 677 <p id="rfc.section.1.1.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.678 </p>679 <p id="rfc.section.1.1.p.2">The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG680 (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII681 character).682 </p>683 677 <h3 id="rfc.section.1.1.1"><a href="#rfc.section.1.1.1">1.1.1</a> <a id="core.rules" href="#core.rules">Core Rules</a></h3> 684 <p id="rfc.section.1.1.1.p.1">The core rules below are defined in <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>: 685 </p> 686 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#core.rules" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>> 687 <a href="#core.rules" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>> 688 <a href="#core.rules" class="smpl">word</a> = <word, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>> 689 </pre><h3 id="rfc.section.1.1.2"><a href="#rfc.section.1.1.2">1.1.2</a> <a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3> 690 <p id="rfc.section.1.1.2.p.1">The ABNF rules below are defined in other parts:</p> 691 <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.7</a>> 692 <a href="#abnf.dependencies" class="smpl">partial-URI</a> = <partial-URI, 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#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 693 <a href="#abnf.dependencies" class="smpl">qvalue</a> = <qvalue, 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#quality.values" title="Quality Values">Section 4.3.1</a>> 694 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1> 678 <h3 id="rfc.section.1.1.2"><a href="#rfc.section.1.1.2">1.1.2</a> <a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3> 679 <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1> 695 680 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="character.sets" href="#character.sets">Character Encodings (charset)</a></h2> 696 681 <p id="rfc.section.2.1.p.1">HTTP uses charset names to indicate the character encoding of a textual representation.</p> … … 700 685 </p> 701 686 </div> 702 <div id="rfc.figure.u. 3"></div><pre class="inline"><span id="rfc.iref.g.1"></span> <a href="#rule.charset" class="smpl">charset</a> = <a href="#core.rules" class="smpl">token</a>687 <div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span> <a href="#rule.charset" class="smpl">charset</a> = <a href="#core.rules" class="smpl">token</a> 703 688 </pre><p id="rfc.section.2.1.p.4">Although HTTP allows an arbitrary token to be used as a charset value, any token that has a predefined value within the IANA 704 689 Character Set registry <em class="bcp14">MUST</em> represent the character encoding defined by that registry. Applications <em class="bcp14">SHOULD</em> limit their use of character encodings to those defined within the IANA registry. … … 716 701 directly, and only decoded by the recipient. 717 702 </p> 718 <div id="rfc.figure.u. 4"></div><pre class="inline"><span id="rfc.iref.g.2"></span> <a href="#content.codings" class="smpl">content-coding</a> = <a href="#core.rules" class="smpl">token</a>703 <div id="rfc.figure.u.2"></div><pre class="inline"><span id="rfc.iref.g.2"></span> <a href="#content.codings" class="smpl">content-coding</a> = <a href="#core.rules" class="smpl">token</a> 719 704 </pre><p id="rfc.section.2.2.p.3">All content-coding values are case-insensitive. HTTP/1.1 uses content-coding values in the Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.1" title="Accept-Encoding">Section 6.3</a>) and Content-Encoding (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.1" title="Content-Encoding">Section 6.5</a>) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding 720 705 mechanism will be required to remove the encoding. … … 723 708 </p> 724 709 <ul class="empty"> 725 <li>See <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 4.2.1</a> of <a href="#Part1" id="rfc.xref.Part1. 9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.710 <li>See <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 4.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 726 711 </li> 727 712 </ul> … … 729 714 </p> 730 715 <ul class="empty"> 731 <li>See <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 4.2.2</a> of <a href="#Part1" id="rfc.xref.Part1. 10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.716 <li>See <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 4.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 732 717 </li> 733 718 </ul> … … 735 720 </p> 736 721 <ul class="empty"> 737 <li>See <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 4.2.3</a> of <a href="#Part1" id="rfc.xref.Part1. 11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.722 <li>See <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 4.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 738 723 </li> 739 724 </ul> … … 747 732 <li>Pointer to specification text</li> 748 733 </ul> 749 <p id="rfc.section.2.2.1.p.3">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 4</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>), unless the encoding transformation is identical (as is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).734 <p id="rfc.section.2.2.1.p.3">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 4</a> of <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), unless the encoding transformation is identical (as is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 750 735 </p> 751 736 <p id="rfc.section.2.2.1.p.4">Values to be added to this name space require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of content coding defined in this section. … … 756 741 <p id="rfc.section.2.3.p.1">HTTP uses Internet Media Types <a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> in the Content-Type (<a href="#header.content-type" id="rfc.xref.header.content-type.1" title="Content-Type">Section 6.8</a>) and Accept (<a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept">Section 6.1</a>) header fields in order to provide open and extensible data typing and type negotiation. 757 742 </p> 758 <div id="rfc.figure.u. 5"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span> <a href="#media.types" class="smpl">media-type</a> = <a href="#media.types" class="smpl">type</a> "/" <a href="#media.types" class="smpl">subtype</a> *( <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">parameter</a> )743 <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span> <a href="#media.types" class="smpl">media-type</a> = <a href="#media.types" class="smpl">type</a> "/" <a href="#media.types" class="smpl">subtype</a> *( <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">parameter</a> ) 759 744 <a href="#media.types" class="smpl">type</a> = <a href="#core.rules" class="smpl">token</a> 760 745 <a href="#media.types" class="smpl">subtype</a> = <a href="#core.rules" class="smpl">token</a> … … 763 748 </p> 764 749 </div> 765 <div id="rfc.figure.u. 6"></div><pre class="inline"><span id="rfc.iref.g.7"></span><span id="rfc.iref.g.8"></span><span id="rfc.iref.g.9"></span> <a href="#rule.parameter" class="smpl">parameter</a> = <a href="#rule.parameter" class="smpl">attribute</a> "=" <a href="#rule.parameter" class="smpl">value</a>750 <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.7"></span><span id="rfc.iref.g.8"></span><span id="rfc.iref.g.9"></span> <a href="#rule.parameter" class="smpl">parameter</a> = <a href="#rule.parameter" class="smpl">attribute</a> "=" <a href="#rule.parameter" class="smpl">value</a> 766 751 <a href="#rule.parameter" class="smpl">attribute</a> = <a href="#core.rules" class="smpl">token</a> 767 752 <a href="#rule.parameter" class="smpl">value</a> = <a href="#core.rules" class="smpl">word</a> … … 814 799 of subtags: 815 800 </p> 816 <div id="rfc.figure.u. 7"></div><pre class="inline"><span id="rfc.iref.g.10"></span> <a href="#language.tags" class="smpl">language-tag</a> = <Language-Tag, defined in <a href="#RFC5646" id="rfc.xref.RFC5646.2"><cite title="Tags for Identifying Languages">[RFC5646]</cite></a>, <a href="http://tools.ietf.org/html/rfc5646#section-2.1">Section 2.1</a>>801 <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.10"></span> <a href="#language.tags" class="smpl">language-tag</a> = <Language-Tag, defined in <a href="#RFC5646" id="rfc.xref.RFC5646.2"><cite title="Tags for Identifying Languages">[RFC5646]</cite></a>, <a href="http://tools.ietf.org/html/rfc5646#section-2.1">Section 2.1</a>> 817 802 </pre><p id="rfc.section.2.4.p.4">White space is not allowed within the tag and all tags are case-insensitive. The name space of language subtags is administered 818 803 by the IANA (see <<a href="http://www.iana.org/assignments/language-subtag-registry">http://www.iana.org/assignments/language-subtag-registry</a>>). 819 804 </p> 820 <div id="rfc.figure.u. 8"></div>805 <div id="rfc.figure.u.6"></div> 821 806 <p>Example tags include:</p> <pre class="text"> en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN 822 807 </pre> <p id="rfc.section.2.4.p.6">See <a href="#RFC5646" id="rfc.xref.RFC5646.3"><cite title="Tags for Identifying Languages">[RFC5646]</cite></a> for further information. … … 847 832 <tr> 848 833 <td class="left">Content-Length</td> 849 <td class="left"><a href="p1-messaging.html#header.content-length" title="Content-Length">Section 3.3.2</a> of <a href="#Part1" id="rfc.xref.Part1. 14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>834 <td class="left"><a href="p1-messaging.html#header.content-length" title="Content-Length">Section 3.3.2</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td> 850 835 </tr> 851 836 <tr> … … 857 842 </div> 858 843 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="payload.body" href="#payload.body">Payload Body</a></h2> 859 <p id="rfc.section.3.2.p.1">A payload body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1. 15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The payload body is obtained from the message body by decoding any Transfer-Encoding that might have been applied to ensure844 <p id="rfc.section.3.2.p.1">A payload body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The payload body is obtained from the message body by decoding any Transfer-Encoding that might have been applied to ensure 860 845 safe and proper transfer of the message. 861 846 </p> … … 945 930 a two-layer, ordered encoding model: 946 931 </p> 947 <div id="rfc.figure.u. 9"></div><pre class="text"> representation-data := Content-Encoding( Content-Type( bits ) )932 <div id="rfc.figure.u.7"></div><pre class="text"> representation-data := Content-Encoding( Content-Type( bits ) ) 948 933 </pre><p id="rfc.section.4.2.p.4">Content-Type specifies the media type of the underlying data, which defines both the data format and how that data <em class="bcp14">SHOULD</em> be processed by the recipient (within the scope of the request method semantics). Any HTTP/1.1 message containing a payload 949 934 body <em class="bcp14">SHOULD</em> include a Content-Type header field defining the media type of the associated representation unless that metadata is unknown … … 1013 998 that doesn't conform to them is better than sending a 406 (Not Acceptable) response. 1014 999 </p> 1015 <p id="rfc.section.5.1.p.5">Many of the mechanisms for expressing preferences use quality values to declare relative preference. See <a href="p1-messaging.html#quality.values" title="Quality Values">Section 4.3.1</a> of <a href="#Part1" id="rfc.xref.Part1. 16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for more information.1000 <p id="rfc.section.5.1.p.5">Many of the mechanisms for expressing preferences use quality values to declare relative preference. See <a href="p1-messaging.html#quality.values" title="Quality Values">Section 4.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for more information. 1016 1001 </p> 1017 1002 <p id="rfc.section.5.1.p.6">HTTP/1.1 includes the following header fields for enabling server-driven negotiation through description of user agent capabilities … … 1053 1038 for an in-line image. 1054 1039 </p> 1055 <div id="rfc.figure.u. 10"></div><pre class="inline"><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span> <a href="#header.accept" class="smpl">Accept</a> = #( <a href="#header.accept" class="smpl">media-range</a> [ <a href="#header.accept" class="smpl">accept-params</a> ] )1040 <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span> <a href="#header.accept" class="smpl">Accept</a> = #( <a href="#header.accept" class="smpl">media-range</a> [ <a href="#header.accept" class="smpl">accept-params</a> ] ) 1056 1041 1057 1042 <a href="#header.accept" class="smpl">media-range</a> = ( "*/*" … … 1066 1051 <p id="rfc.section.6.1.p.4">Each media-range <em class="bcp14">MAY</em> be followed by one or more accept-params, beginning with the "q" parameter for indicating a relative quality factor. The first 1067 1052 "q" parameter (if any) separates the media-range parameter(s) from the accept-params. Quality factors allow the user or user 1068 agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="p1-messaging.html#quality.values" title="Quality Values">Section 4.3.1</a> of <a href="#Part1" id="rfc.xref.Part1. 17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The default value is q=1.1053 agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="p1-messaging.html#quality.values" title="Quality Values">Section 4.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The default value is q=1. 1069 1054 </p> 1070 1055 <div class="note" id="rfc.section.6.1.p.5"> … … 1076 1061 </div> 1077 1062 <p id="rfc.section.6.1.p.6">The example</p> 1078 <div id="rfc.figure.u. 11"></div><pre class="text"> Accept: audio/*; q=0.2, audio/basic1063 <div id="rfc.figure.u.9"></div><pre class="text"> Accept: audio/*; q=0.2, audio/basic 1079 1064 </pre><p id="rfc.section.6.1.p.8"> <em class="bcp14">SHOULD</em> be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in 1080 1065 quality". … … 1086 1071 </p> 1087 1072 <p id="rfc.section.6.1.p.10">A more elaborate example is</p> 1088 <div id="rfc.figure.u.1 2"></div><pre class="text"> Accept: text/plain; q=0.5, text/html,1073 <div id="rfc.figure.u.10"></div><pre class="text"> Accept: text/plain; q=0.5, text/html, 1089 1074 text/x-dvi; q=0.8, text/x-c 1090 1075 </pre><p id="rfc.section.6.1.p.12">Verbally, this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist, then … … 1094 1079 to a given type, the most specific reference has precedence. For example, 1095 1080 </p> 1096 <div id="rfc.figure.u.1 3"></div><pre class="text"> Accept: text/*, text/plain, text/plain;format=flowed, */*1081 <div id="rfc.figure.u.11"></div><pre class="text"> Accept: text/*, text/plain, text/plain;format=flowed, */* 1097 1082 </pre><p id="rfc.section.6.1.p.15">have the following precedence: </p> 1098 1083 <ol> … … 1105 1090 which matches that type. For example, 1106 1091 </p> 1107 <div id="rfc.figure.u.1 4"></div><pre class="text"> Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,1092 <div id="rfc.figure.u.12"></div><pre class="text"> Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, 1108 1093 text/html;level=2;q=0.4, */*;q=0.5 1109 1094 </pre><p id="rfc.section.6.1.p.18">would cause the following values to be associated:</p> … … 1154 1139 that capability to a server which is capable of representing documents in those character encodings. 1155 1140 </p> 1156 <div id="rfc.figure.u.1 5"></div><pre class="inline"><span id="rfc.iref.g.15"></span> <a href="#header.accept-charset" class="smpl">Accept-Charset</a> = 1#( ( <a href="#rule.charset" class="smpl">charset</a> / "*" )1141 <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.15"></span> <a href="#header.accept-charset" class="smpl">Accept-Charset</a> = 1#( ( <a href="#rule.charset" class="smpl">charset</a> / "*" ) 1157 1142 [ <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> "q=" <a href="#abnf.dependencies" class="smpl">qvalue</a> ] ) 1158 1143 </pre><p id="rfc.section.6.2.p.3">Character encoding values (a.k.a., charsets) are described in <a href="#character.sets" title="Character Encodings (charset)">Section 2.1</a>. Each charset <em class="bcp14">MAY</em> be given an associated quality value which represents the user's preference for that charset. The default value is q=1. An 1159 1144 example is 1160 1145 </p> 1161 <div id="rfc.figure.u.1 6"></div><pre class="text"> Accept-Charset: iso-8859-5, unicode-1-1;q=0.81146 <div id="rfc.figure.u.14"></div><pre class="text"> Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 1162 1147 </pre><p id="rfc.section.6.2.p.5">The special value "*", if present in the Accept-Charset field, matches every character encoding which is not mentioned elsewhere 1163 1148 in the Accept-Charset field. If no "*" is present in an Accept-Charset field, then all character encodings not explicitly … … 1175 1160 no encoding is preferred. 1176 1161 </p> 1177 <div id="rfc.figure.u.1 7"></div><pre class="inline"><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span> <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> = #( <a href="#header.accept-encoding" class="smpl">codings</a> [ <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> "q=" <a href="#abnf.dependencies" class="smpl">qvalue</a> ] )1162 <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span> <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> = #( <a href="#header.accept-encoding" class="smpl">codings</a> [ <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> "q=" <a href="#abnf.dependencies" class="smpl">qvalue</a> ] ) 1178 1163 <a href="#header.accept-encoding" class="smpl">codings</a> = <a href="#content.codings" class="smpl">content-coding</a> / "identity" / "*" 1179 1164 </pre><p id="rfc.section.6.3.p.3">Each codings value <em class="bcp14">MAY</em> be given an associated quality value which represents the preference for that encoding. The default value is q=1. 1180 1165 </p> 1181 1166 <p id="rfc.section.6.3.p.4">For example,</p> 1182 <div id="rfc.figure.u.1 8"></div><pre class="text"> Accept-Encoding: compress, gzip1167 <div id="rfc.figure.u.16"></div><pre class="text"> Accept-Encoding: compress, gzip 1183 1168 Accept-Encoding: 1184 1169 Accept-Encoding: * … … 1196 1181 </li> 1197 1182 <li>If the representation's content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable 1198 unless it is accompanied by a qvalue of 0. (As defined in <a href="p1-messaging.html#quality.values" title="Quality Values">Section 4.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.1 8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, a qvalue of 0 means "not acceptable".)1183 unless it is accompanied by a qvalue of 0. (As defined in <a href="p1-messaging.html#quality.values" title="Quality Values">Section 4.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, a qvalue of 0 means "not acceptable".) 1199 1184 </li> 1200 1185 <li>If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.</li> … … 1218 1203 in the response. Language tags are defined in <a href="#language.tags" title="Language Tags">Section 2.4</a>. 1219 1204 </p> 1220 <div id="rfc.figure.u.1 9"></div><pre class="inline"><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span> <a href="#header.accept-language" class="smpl">Accept-Language</a> =1205 <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span> <a href="#header.accept-language" class="smpl">Accept-Language</a> = 1221 1206 1#( <a href="#header.accept-language" class="smpl">language-range</a> [ <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> "q=" <a href="#abnf.dependencies" class="smpl">qvalue</a> ] ) 1222 1207 <a href="#header.accept-language" class="smpl">language-range</a> = … … 1225 1210 languages specified by that range. The quality value defaults to "q=1". For example, 1226 1211 </p> 1227 <div id="rfc.figure.u. 20"></div><pre class="text"> Accept-Language: da, en-gb;q=0.8, en;q=0.71212 <div id="rfc.figure.u.18"></div><pre class="text"> Accept-Language: da, en-gb;q=0.8, en;q=0.7 1228 1213 </pre><p id="rfc.section.6.4.p.5">would mean: "I prefer Danish, but will accept British English and other types of English". (see also <a href="http://tools.ietf.org/html/rfc4647#section-2.3">Section 2.3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.2"><cite title="Matching of Language Tags">[RFC4647]</cite></a>) 1229 1214 </p> … … 1255 1240 identity of its underlying media type. 1256 1241 </p> 1257 <div id="rfc.figure.u. 21"></div><pre class="inline"><span id="rfc.iref.g.20"></span> <a href="#header.content-encoding" class="smpl">Content-Encoding</a> = 1#<a href="#content.codings" class="smpl">content-coding</a>1242 <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.20"></span> <a href="#header.content-encoding" class="smpl">Content-Encoding</a> = 1#<a href="#content.codings" class="smpl">content-coding</a> 1258 1243 </pre><p id="rfc.section.6.5.p.3">Content codings are defined in <a href="#content.codings" title="Content Codings">Section 2.2</a>. An example of its use is 1259 1244 </p> 1260 <div id="rfc.figure.u.2 2"></div><pre class="text"> Content-Encoding: gzip1245 <div id="rfc.figure.u.20"></div><pre class="text"> Content-Encoding: gzip 1261 1246 </pre><p id="rfc.section.6.5.p.5">The content-coding is a characteristic of the representation. Typically, the representation body is stored with this encoding 1262 1247 and is only decoded before rendering or analogous usage. However, a transforming proxy <em class="bcp14">MAY</em> modify the content-coding if the new coding is known to be acceptable to the recipient, unless the "no-transform" cache-control … … 1282 1267 that this might not be equivalent to all the languages used within the representation. 1283 1268 </p> 1284 <div id="rfc.figure.u.2 3"></div><pre class="inline"><span id="rfc.iref.g.21"></span> <a href="#header.content-language" class="smpl">Content-Language</a> = 1#<a href="#language.tags" class="smpl">language-tag</a>1269 <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.21"></span> <a href="#header.content-language" class="smpl">Content-Language</a> = 1#<a href="#language.tags" class="smpl">language-tag</a> 1285 1270 </pre><p id="rfc.section.6.6.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section 2.4</a>. The primary purpose of Content-Language is to allow a user to identify and differentiate representations according to the 1286 1271 user's own preferred language. Thus, if the body content is intended only for a Danish-literate audience, the appropriate 1287 1272 field is 1288 1273 </p> 1289 <div id="rfc.figure.u.2 4"></div><pre class="text"> Content-Language: da1274 <div id="rfc.figure.u.22"></div><pre class="text"> Content-Language: da 1290 1275 </pre><p id="rfc.section.6.6.p.5">If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean 1291 1276 that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language … … 1295 1280 simultaneously in the original Maori and English versions, would call for 1296 1281 </p> 1297 <div id="rfc.figure.u.2 5"></div><pre class="text"> Content-Language: mi, en1282 <div id="rfc.figure.u.23"></div><pre class="text"> Content-Language: mi, en 1298 1283 </pre><p id="rfc.section.6.6.p.8">However, just because multiple languages are present within a representation does not mean that it is intended for multiple 1299 1284 linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin", which is clearly … … 1309 1294 would contain the same representation that is enclosed as payload in this message. 1310 1295 </p> 1311 <div id="rfc.figure.u.2 6"></div><pre class="inline"><span id="rfc.iref.g.22"></span> <a href="#header.content-location" class="smpl">Content-Location</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a>1312 </pre><p id="rfc.section.6.7.p.3">The Content-Location value is not a replacement for the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.1 9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME1296 <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.22"></span> <a href="#header.content-location" class="smpl">Content-Location</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a> 1297 </pre><p id="rfc.section.6.7.p.3">The Content-Location value is not a replacement for the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME 1313 1298 body parts in <a href="http://tools.ietf.org/html/rfc2557#section-4">Section 4</a> of <a href="#RFC2557" id="rfc.xref.RFC2557.1"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a>. However, its appearance in an HTTP message has some special implications for HTTP recipients. 1314 1299 </p> … … 1350 1335 the media type is that which would have been sent had the request been a GET. 1351 1336 </p> 1352 <div id="rfc.figure.u.2 7"></div><pre class="inline"><span id="rfc.iref.g.23"></span> <a href="#header.content-type" class="smpl">Content-Type</a> = <a href="#media.types" class="smpl">media-type</a>1337 <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.23"></span> <a href="#header.content-type" class="smpl">Content-Type</a> = <a href="#media.types" class="smpl">media-type</a> 1353 1338 </pre><p id="rfc.section.6.8.p.3">Media types are defined in <a href="#media.types" title="Media Types">Section 2.3</a>. An example of the field is 1354 1339 </p> 1355 <div id="rfc.figure.u.2 8"></div><pre class="text"> Content-Type: text/html; charset=ISO-8859-41340 <div id="rfc.figure.u.26"></div><pre class="text"> Content-Type: text/html; charset=ISO-8859-4 1356 1341 </pre><p id="rfc.section.6.8.p.5">Further discussion of Content-Type is provided in <a href="#representation.data" title="Representation Data">Section 4.2</a>. 1357 1342 </p> … … 1376 1361 <td class="left">compress</td> 1377 1362 <td class="left">UNIX "compress" program method</td> 1378 <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 4.2.1</a> of <a href="#Part1" id="rfc.xref.Part1. 20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>1363 <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 4.2.1</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> 1379 1364 </td> 1380 1365 </tr> … … 1383 1368 <td class="left">"deflate" compression mechanism (<a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>) 1384 1369 </td> 1385 <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 4.2.2</a> of <a href="#Part1" id="rfc.xref.Part1. 21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>1370 <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 4.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> 1386 1371 </td> 1387 1372 </tr> … … 1389 1374 <td class="left">gzip</td> 1390 1375 <td class="left">Same as GNU zip <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a></td> 1391 <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 4.2.3</a> of <a href="#Part1" id="rfc.xref.Part1. 22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>1376 <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 4.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> 1392 1377 </td> 1393 1378 </tr> … … 1429 1414 <h2 id="rfc.references.1"><a href="#rfc.section.9.1" id="rfc.section.9.1">9.1</a> Normative References 1430 1415 </h2> 1431 <table> 1416 <table> 1432 1417 <tr> 1433 1418 <td class="reference"><b id="Part1">[Part1]</b></td> … … 1483 1468 <td class="reference"><b id="RFC4647">[RFC4647]</b></td> 1484 1469 <td class="top"><a href="mailto:addison@inter-locale.com" title="Yahoo! Inc.">Phillips, A., Ed.</a> and <a href="mailto:mark.davis@macchiato.com" title="Google">M. Davis, Ed.</a>, “<a href="http://tools.ietf.org/html/rfc4647">Matching of Language Tags</a>”, BCP 47, RFC 4647, September 2006. 1485 </td>1486 </tr>1487 <tr>1488 <td class="reference"><b id="RFC5234">[RFC5234]</b></td>1489 <td class="top"><a href="mailto:dcrocker@bbiw.net" title="Brandenburg InternetWorking">Crocker, D., Ed.</a> and <a href="mailto:paul.overell@thus.net" title="THUS plc.">P. Overell</a>, “<a href="http://tools.ietf.org/html/rfc5234">Augmented BNF for Syntax Specifications: ABNF</a>”, STD 68, RFC 5234, January 2008.1490 1470 </td> 1491 1471 </tr> … … 1604 1584 MIME environments. 1605 1585 </p> 1606 <div id="rfc.figure.u.2 9"></div><pre class="inline"><span id="rfc.iref.g.24"></span> <a href="#mime-version" class="smpl">MIME-Version</a> = 1*<a href="#notation" class="smpl">DIGIT</a> "." 1*<a href="#notation" class="smpl">DIGIT</a>1586 <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.24"></span> <a href="#mime-version" class="smpl">MIME-Version</a> = 1*<a href="#notation" class="smpl">DIGIT</a> "." 1*<a href="#notation" class="smpl">DIGIT</a> 1607 1587 </pre><p id="rfc.section.A.1.p.3">MIME version "1.0" is the default for use in HTTP/1.1. However, HTTP/1.1 message parsing and semantics are defined by this 1608 1588 document and not the MIME specification. … … 1640 1620 </p> 1641 1621 <h2 id="rfc.section.A.6"><a href="#rfc.section.A.6">A.6</a> <a id="introduction.of.transfer-encoding" href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></h2> 1642 <p id="rfc.section.A.6.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 3.3.1</a> of <a href="#Part1" id="rfc.xref.Part1. 23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol.1622 <p id="rfc.section.A.6.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 3.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol. 1643 1623 </p> 1644 1624 <h2 id="rfc.section.A.7"><a href="#rfc.section.A.7">A.7</a> <a id="mhtml.line.length" href="#mhtml.line.length">MHTML and Line Length Limitations</a></h2> … … 2000 1980 </li> 2001 1981 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 2002 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1.1</a>, <a href="#rfc.xref.Part1.2">1.1.1</a>, <a href="#rfc.xref.Part1.3">1.1.1</a>, <a href="#rfc.xref.Part1.4">1.1.1</a>, <a href="#rfc.xref.Part1.5">1.1.1</a>, <a href="#rfc.xref.Part1.6">1.1.2</a>, <a href="#rfc.xref.Part1.7">1.1.2</a>, <a href="#rfc.xref.Part1.8">1.1.2</a>, <a href="#rfc.xref.Part1.9">2.2</a>, <a href="#rfc.xref.Part1.10">2.2</a>, <a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.12">2.2.1</a>, <a href="#rfc.xref.Part1.13">2.2.1</a>, <a href="#rfc.xref.Part1.14">3.1</a>, <a href="#rfc.xref.Part1.15">3.2</a>, <a href="#rfc.xref.Part1.16">5.1</a>, <a href="#rfc.xref.Part1.17">6.1</a>, <a href="#rfc.xref.Part1.18">6.3</a>, <a href="#rfc.xref.Part1.19">6.7</a>, <a href="#rfc.xref.Part1.20">7.1</a>, <a href="#rfc.xref.Part1.21">7.1</a>, <a href="#rfc.xref.Part1.22">7.1</a>, <a href="#Part1"><b>9.1</b></a>, <a href="#rfc.xref.Part1.23">A.6</a><ul> 2003 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.1">1.1</a></li> 2004 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.6">1.1.2</a>, <a href="#rfc.xref.Part1.7">1.1.2</a></li> 2005 <li><em>Section 3.2.1</em> <a href="#rfc.xref.Part1.3">1.1.1</a></li> 2006 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part1.4">1.1.1</a>, <a href="#rfc.xref.Part1.5">1.1.1</a></li> 2007 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.15">3.2</a></li> 2008 <li><em>Section 3.3.1</em> <a href="#rfc.xref.Part1.23">A.6</a></li> 2009 <li><em>Section 3.3.2</em> <a href="#rfc.xref.Part1.14">3.1</a></li> 2010 <li><em>Section 4</em> <a href="#rfc.xref.Part1.12">2.2.1</a></li> 2011 <li><em>Section 4.2.1</em> <a href="#rfc.xref.Part1.9">2.2</a>, <a href="#rfc.xref.Part1.20">7.1</a></li> 2012 <li><em>Section 4.2</em> <a href="#rfc.xref.Part1.13">2.2.1</a></li> 2013 <li><em>Section 4.2.2</em> <a href="#rfc.xref.Part1.10">2.2</a>, <a href="#rfc.xref.Part1.21">7.1</a></li> 2014 <li><em>Section 4.2.3</em> <a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.22">7.1</a></li> 2015 <li><em>Section 4.3.1</em> <a href="#rfc.xref.Part1.8">1.1.2</a>, <a href="#rfc.xref.Part1.16">5.1</a>, <a href="#rfc.xref.Part1.17">6.1</a>, <a href="#rfc.xref.Part1.18">6.3</a></li> 2016 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.19">6.7</a></li> 1982 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">2.2</a>, <a href="#rfc.xref.Part1.2">2.2</a>, <a href="#rfc.xref.Part1.3">2.2</a>, <a href="#rfc.xref.Part1.4">2.2.1</a>, <a href="#rfc.xref.Part1.5">2.2.1</a>, <a href="#rfc.xref.Part1.6">3.1</a>, <a href="#rfc.xref.Part1.7">3.2</a>, <a href="#rfc.xref.Part1.8">5.1</a>, <a href="#rfc.xref.Part1.9">6.1</a>, <a href="#rfc.xref.Part1.10">6.3</a>, <a href="#rfc.xref.Part1.11">6.7</a>, <a href="#rfc.xref.Part1.12">7.1</a>, <a href="#rfc.xref.Part1.13">7.1</a>, <a href="#rfc.xref.Part1.14">7.1</a>, <a href="#Part1"><b>9.1</b></a>, <a href="#rfc.xref.Part1.15">A.6</a><ul> 1983 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.7">3.2</a></li> 1984 <li><em>Section 3.3.1</em> <a href="#rfc.xref.Part1.15">A.6</a></li> 1985 <li><em>Section 3.3.2</em> <a href="#rfc.xref.Part1.6">3.1</a></li> 1986 <li><em>Section 4</em> <a href="#rfc.xref.Part1.4">2.2.1</a></li> 1987 <li><em>Section 4.2.1</em> <a href="#rfc.xref.Part1.1">2.2</a>, <a href="#rfc.xref.Part1.12">7.1</a></li> 1988 <li><em>Section 4.2</em> <a href="#rfc.xref.Part1.5">2.2.1</a></li> 1989 <li><em>Section 4.2.2</em> <a href="#rfc.xref.Part1.2">2.2</a>, <a href="#rfc.xref.Part1.13">7.1</a></li> 1990 <li><em>Section 4.2.3</em> <a href="#rfc.xref.Part1.3">2.2</a>, <a href="#rfc.xref.Part1.14">7.1</a></li> 1991 <li><em>Section 4.3.1</em> <a href="#rfc.xref.Part1.8">5.1</a>, <a href="#rfc.xref.Part1.9">6.1</a>, <a href="#rfc.xref.Part1.10">6.3</a></li> 1992 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.11">6.7</a></li> 2017 1993 </ul> 2018 1994 </li> … … 2081 2057 </ul> 2082 2058 </li> 2083 <li><em>RFC5234</em> <a href="#rfc.xref.RFC5234.1">1.1</a>, <a href="#rfc.xref.RFC5234.2">1.1</a>, <a href="#RFC5234"><b>9.1</b></a><ul>2084 <li><em>Appendix B.1</em> <a href="#rfc.xref.RFC5234.2">1.1</a></li>2085 </ul>2086 </li>2087 2059 <li><em>RFC5322</em> <a href="#RFC5322"><b>9.2</b></a>, <a href="#rfc.xref.RFC5322.1">A</a></li> 2088 2060 <li><em>RFC5646</em> <a href="#rfc.xref.RFC5646.1">2.4</a>, <a href="#rfc.xref.RFC5646.2">2.4</a>, <a href="#rfc.xref.RFC5646.3">2.4</a>, <a href="#RFC5646"><b>9.1</b></a><ul> -
draft-ietf-httpbis/latest/p3-payload.xml
r1641 r1642 134 134 <x:anchor-alias value="OCTET"/> 135 135 <x:anchor-alias value="VCHAR"/> 136 <t>137 This specification uses the Augmented Backus-Naur Form (ABNF) notation138 of <xref target="RFC5234"/> with the list rule extension defined in139 ¬ation;.<!-- <xref target="collected.abnf"/> shows the collected ABNF140 with the list rule expanded.-->141 </t>142 <t>143 The following core rules are included by144 reference, as defined in <xref target="RFC5234" x:fmt="," x:sec="B.1"/>:145 ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls),146 DIGIT (decimal 0-9), DQUOTE (double quote),147 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed),148 OCTET (any 8-bit sequence of data), SP (space), and149 VCHAR (any visible US-ASCII character).150 </t>151 136 152 137 <section title="Core Rules" anchor="core.rules"> … … 154 139 <x:anchor-alias value="word"/> 155 140 <x:anchor-alias value="OWS"/> 156 <t>157 The core rules below are defined in <xref target="Part1"/>:158 </t>159 <figure><artwork type="abnf2616">160 <x:ref>OWS</x:ref> = <OWS, defined in &whitespace;>161 <x:ref>token</x:ref> = <token, defined in &field-components;>162 <x:ref>word</x:ref> = <word, defined in &field-components;>163 </artwork></figure>164 141 </section> 165 142 … … 168 145 <x:anchor-alias value="partial-URI"/> 169 146 <x:anchor-alias value="qvalue"/> 170 <t>171 The ABNF rules below are defined in other parts:172 </t>173 <figure><!--Part1--><artwork type="abnf2616">174 <x:ref>absolute-URI</x:ref> = <absolute-URI, defined in &uri;>175 <x:ref>partial-URI</x:ref> = <partial-URI, defined in &uri;>176 <x:ref>qvalue</x:ref> = <qvalue, defined in &qvalue;>177 </artwork></figure>178 147 </section> 179 148 … … 1631 1600 </reference> 1632 1601 1633 <reference anchor="RFC5234">1634 <front>1635 <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title>1636 <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor">1637 <organization>Brandenburg InternetWorking</organization>1638 <address>1639 <email>dcrocker@bbiw.net</email>1640 </address>1641 </author>1642 <author initials="P." surname="Overell" fullname="Paul Overell">1643 <organization>THUS plc.</organization>1644 <address>1645 <email>paul.overell@thus.net</email>1646 </address>1647 </author>1648 <date month="January" year="2008"/>1649 </front>1650 <seriesInfo name="STD" value="68"/>1651 <seriesInfo name="RFC" value="5234"/>1652 </reference>1653 1654 1602 <reference anchor='RFC5646'> 1655 1603 <front>
Note: See TracChangeset
for help on using the changeset viewer.