Changeset 1642 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 30/03/12 14:52:26 (9 years ago)
- File:
-
- 1 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>
Note: See TracChangeset
for help on using the changeset viewer.