Changeset 823 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 26/05/10 17:25:13 (11 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r818 r823 403 403 <meta name="dct.creator" content="Reschke, J. F."> 404 404 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 405 <meta name="dct.issued" scheme="ISO8601" content="2010-05- 07">405 <meta name="dct.issued" scheme="ISO8601" content="2010-05-26"> 406 406 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 407 407 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and response-header fields."> … … 434 434 </tr> 435 435 <tr> 436 <td class="left">Expires: November 8, 2010</td>436 <td class="left">Expires: November 27, 2010</td> 437 437 <td class="right">HP</td> 438 438 </tr> … … 487 487 <tr> 488 488 <td class="left"></td> 489 <td class="right">May 7, 2010</td>489 <td class="right">May 26, 2010</td> 490 490 </tr> 491 491 </tbody> … … 514 514 in progress”. 515 515 </p> 516 <p>This Internet-Draft will expire in November 8, 2010.</p>516 <p>This Internet-Draft will expire in November 27, 2010.</p> 517 517 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 518 518 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 753 753 <WWW-Authenticate, defined in <a href="#Part7" id="rfc.xref.Part7.4"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 3.4</a>> 754 754 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="method" href="#method">Method</a></h1> 755 <p id="rfc.section.2.p.1">The Method token indicates the method to be performed on the resource identified by the request-target. The method is case-sensitive.</p> 755 <p id="rfc.section.2.p.1">The Method token indicates the method to be performed on the resource identified by the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.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>). The method is case-sensitive. 756 </p> 756 757 <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span> <a href="#method" class="smpl">Method</a> = %x4F.50.54.49.4F.4E.53 ; "OPTIONS", <a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">Section 7.2</a> 757 758 / %x47.45.54 ; "GET", <a href="#GET" id="rfc.xref.GET.1" title="GET">Section 7.3</a> … … 796 797 / <a href="#header.expect" class="smpl">Expect</a> ; <a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section 9.2</a> 797 798 / <a href="#header.from" class="smpl">From</a> ; <a href="#header.from" id="rfc.xref.header.from.1" title="From">Section 9.3</a> 798 / <a href="#abnf.dependencies" class="smpl">Host</a> ; <a href="#Part1" id="rfc.xref.Part1.1 7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.host" title="Host">Section 9.4</a>799 / <a href="#abnf.dependencies" class="smpl">Host</a> ; <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.host" title="Host">Section 9.4</a> 799 800 / <a href="#abnf.dependencies" class="smpl">If-Match</a> ; <a href="#Part4" id="rfc.xref.Part4.6"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-match" title="If-Match">Section 6.2</a> 800 801 / <a href="#abnf.dependencies" class="smpl">If-Modified-Since</a> ; <a href="#Part4" id="rfc.xref.Part4.7"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-modified-since" title="If-Modified-Since">Section 6.3</a> … … 806 807 / <a href="#abnf.dependencies" class="smpl">Range</a> ; <a href="#Part5" id="rfc.xref.Part5.5"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.range" title="Range">Section 5.4</a> 807 808 / <a href="#header.referer" class="smpl">Referer</a> ; <a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section 9.6</a> 808 / <a href="#abnf.dependencies" class="smpl">TE</a> ; <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 href="p1-messaging.html#header.upgrade" title="Upgrade">Section 9.8</a>809 / <a href="#abnf.dependencies" class="smpl">TE</a> ; <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 9.8</a> 809 810 / <a href="#header.user-agent" class="smpl">User-Agent</a> ; <a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section 9.9</a> 810 811 </pre><p id="rfc.section.3.p.3">Request-header field names can be extended reliably only in combination with a change in the protocol version. However, new … … 880 881 <p id="rfc.section.5.p.1">The response-header fields allow the server to pass additional information about the response which cannot be placed in the 881 882 Status-Line. These header fields give information about the server and about further access to the resource identified by 882 the request-target.883 the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</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>). 883 884 </p> 884 885 <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.7"></span> <a href="#response.header.fields" class="smpl">response-header</a> = <a href="#abnf.dependencies" class="smpl">Accept-Ranges</a> ; <a href="#Part5" id="rfc.xref.Part5.7"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 5.1</a> … … 901 902 fields are defined in <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. 902 903 </p> 903 <p id="rfc.section.6.p.2">An entity-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. 19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The entity-body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure904 <p id="rfc.section.6.p.2">An entity-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.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The entity-body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure 904 905 safe and proper transfer of the message. 905 906 </p> … … 907 908 <p id="rfc.section.6.1.p.1">It is sometimes necessary to determine the identity of the resource associated with a representation.</p> 908 909 <p id="rfc.section.6.1.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p> 909 <p id="rfc.section.6.1.p.3">In the common case, an HTTP response is a representation of the resource located at the request-URI. However, this is not 910 always the case. To determine the URI of the resource a response is associated with, the following rules are used (with the 911 first applicable one being selected): 910 <p id="rfc.section.6.1.p.3">In the common case, an HTTP response is a representation of the resource located at the Effective Request URI (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.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>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following 911 rules are used (with the first applicable one being selected): 912 912 </p> 913 913 <ol> 914 914 <li>If the response status code is 200 or 203 and the request method was GET, the response is a representation of the resource 915 at the request-URI.915 at the Effective Request URI. 916 916 </li> 917 917 <li>If the response status is 204, 206, or 304 and the request method was GET or HEAD, the response is a partial representation 918 of the resource at the request-URI (see <a href="p6-cache.html#combining.headers" title="Combining Responses">Section 2.7</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 919 </li> 920 <li>If the response has a Content-Location header, and that URI is the same as the request-URI <span class="comment" id="TODO-missref-requri">[<a href="#TODO-missref-requri" class="smpl">TODO-missref-requri</a>: (see [ref])]</span>, the response is a representation of the resource at the request-URI. 921 </li> 922 <li>If the response has a Content-Location header, and that URI is not the same as the request-URI, the response asserts that 923 it is a representation of the resource at the Content-Location URI (but it may not be). 918 of the resource at the Effective Request URI (see <a href="p6-cache.html#combining.headers" title="Combining Responses">Section 2.7</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 919 </li> 920 <li>If the response has a Content-Location header, and that URI is the same as the Effective Request URI, the response is a representation 921 of the resource at the Effective Request URI. 922 </li> 923 <li>If the response has a Content-Location header, and that URI is not the same as the Effective Request URI, the response asserts 924 that it is a representation of the resource at the Content-Location URI (but it may not be). 924 925 </li> 925 926 <li>Otherwise, the response is a representation of an anonymous (i.e., unidentified) resource.</li> 926 927 </ol> 927 <p id="rfc.section.6.1.p.5"> <span class="comment" id="TODO-req-uri">[<a href="#TODO-req-uri" class="smpl">TODO-req-uri</a>: Note that "request-URI" is used here; however, we need to come up with a term to denote "the URI that can be inferred from 928 examining the request-target and the Host header." (see <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/196">http://tools.ietf.org/wg/httpbis/trac/ticket/196</a>>). Also, the comparison function is going to have to be defined somewhere, because we already need to compare URIs for things 929 like cache invalidation.]</span> 928 <p id="rfc.section.6.1.p.5"> <span class="comment" id="TODO-req-uri">[<a href="#TODO-req-uri" class="smpl">TODO-req-uri</a>: The comparison function is going to have to be defined somewhere, because we already need to compare URIs for things like 929 cache invalidation.]</span> 930 930 </p> 931 931 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="method.definitions" href="#method.definitions">Method Definitions</a></h1> … … 958 958 <div id="rfc.iref.m.1"></div> 959 959 <p id="rfc.section.7.2.p.1">The OPTIONS method represents a request for information about the communication options available on the request/response 960 chain identified by the request-target. This method allows the client to determine the options and/or requirements associated961 with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.960 chain identified by the Effective Request URI. This method allows the client to determine the options and/or requirements 961 associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval. 962 962 </p> 963 963 <p id="rfc.section.7.2.p.2">Responses to this method are not cacheable.</p> … … 986 986 <div id="rfc.iref.m.2"></div> 987 987 <p id="rfc.section.7.3.p.1">The GET method means retrieve whatever information (in the form of an entity) currently corresponds to the resource identified 988 by the request-target.989 </p> 990 <p id="rfc.section.7.3.p.2">If the request-target identifies a data-producing process, it is the produced data which shall be returned as the entity in991 the response and not the source text of the process, unless that text happens to be the output of the process.988 by the Effective Request URI. 989 </p> 990 <p id="rfc.section.7.3.p.2">If the Effective Request URI identifies a data-producing process, it is the produced data which shall be returned as the entity 991 in the response and not the source text of the process, unless that text happens to be the output of the process. 992 992 </p> 993 993 <p id="rfc.section.7.3.p.3">The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since, … … 1020 1020 <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a> <a id="POST" href="#POST">POST</a></h2> 1021 1021 <p id="rfc.section.7.5.p.1">The POST method is used to request that the origin server accept the entity enclosed in the request as data to be processed 1022 by the resource identified by the request-target in the Request-Line. POST is designed to allow a uniform method to cover1023 the followingfunctions:1022 by the resource identified by the Effective Request URI. POST is designed to allow a uniform method to cover the following 1023 functions: 1024 1024 </p> 1025 1025 <ul> … … 1029 1029 <li>Extending a database through an append operation.</li> 1030 1030 </ul> 1031 <p id="rfc.section.7.5.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the request-target.</p> 1031 <p id="rfc.section.7.5.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the Effective Request 1032 URI. 1033 </p> 1032 1034 <p id="rfc.section.7.5.p.3">The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 1033 1035 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity … … 1043 1045 <div id="rfc.iref.m.5"></div> 1044 1046 <h2 id="rfc.section.7.6"><a href="#rfc.section.7.6">7.6</a> <a id="PUT" href="#PUT">PUT</a></h2> 1045 <p id="rfc.section.7.6.p.1">The PUT method requests that the enclosed entity be stored at the supplied request-target. If the request-target refers to 1046 an already existing resource, the enclosed entity <em class="bcp14">SHOULD</em> be considered as a modified version of the one residing on the origin server. If the request-target does not point to an existing 1047 resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create 1048 the resource with that URI. If a new resource is created at the request-target, the origin server <em class="bcp14">MUST</em> inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No 1049 Content) response codes <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request. If the resource could not be created or modified with the request-target, 1050 an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the entity <em class="bcp14">MUST NOT</em> ignore any Content-* headers (headers starting with the prefix "Content-") that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases. 1051 </p> 1052 <p id="rfc.section.7.6.p.2">If the request passes through a cache and the request-target identifies one or more currently cached entities, those entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to this method are not cacheable. 1053 </p> 1054 <p id="rfc.section.7.6.p.3">The fundamental difference between the POST and PUT requests is reflected in the different meaning of the request-target. 1055 The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting 1047 <p id="rfc.section.7.6.p.1">The PUT method requests that the enclosed entity be stored at the Effective Request URI. If the Effective Request URI refers 1048 to an already existing resource, the enclosed entity <em class="bcp14">SHOULD</em> be considered as a modified version of the one residing on the origin server. Otherwise, if the Effective Request URI does 1049 not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, 1050 the origin server can create the resource with that URI. 1051 </p> 1052 <p id="rfc.section.7.6.p.2">If a new resource is created at the Effective Request URI, the origin server <em class="bcp14">MUST</em> inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No 1053 Content) response codes <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request. 1054 </p> 1055 <p id="rfc.section.7.6.p.3">If the resource could not be created or modified with the Effective Request URI, an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the entity <em class="bcp14">MUST NOT</em> ignore any Content-* headers (headers starting with the prefix "Content-") that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases. 1056 </p> 1057 <p id="rfc.section.7.6.p.4">If the request passes through a cache and the Effective Request URI identifies one or more currently cached entities, those 1058 entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to this method are not cacheable. 1059 </p> 1060 <p id="rfc.section.7.6.p.5">The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Effective Request 1061 URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting 1056 1062 process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request 1057 1063 identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server <em class="bcp14">MUST NOT</em> attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI, 1058 1064 it <em class="bcp14">MUST</em> send a 301 (Moved Permanently) response; the user agent <em class="bcp14">MAY</em> then make its own decision regarding whether or not to redirect the request. 1059 1065 </p> 1060 <p id="rfc.section.7.6.p. 4">A single resource <em class="bcp14">MAY</em> be identified by many different URIs. For example, an article might have a URI for identifying "the current version" which1066 <p id="rfc.section.7.6.p.6">A single resource <em class="bcp14">MAY</em> be identified by many different URIs. For example, an article might have a URI for identifying "the current version" which 1061 1067 is separate from the URI identifying each particular version. In this case, a PUT request on a general URI might result in 1062 1068 several other URIs being defined by the origin server. 1063 1069 </p> 1064 <p id="rfc.section.7.6.p. 5">HTTP/1.1 does not define how a PUT method affects the state of an origin server.</p>1065 <p id="rfc.section.7.6.p. 6">Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request <em class="bcp14">SHOULD</em> be applied to the resource created or modified by the PUT.1070 <p id="rfc.section.7.6.p.7">HTTP/1.1 does not define how a PUT method affects the state of an origin server.</p> 1071 <p id="rfc.section.7.6.p.8">Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request <em class="bcp14">SHOULD</em> be applied to the resource created or modified by the PUT. 1066 1072 </p> 1067 1073 <div id="rfc.iref.d.1"></div> 1068 1074 <div id="rfc.iref.m.6"></div> 1069 1075 <h2 id="rfc.section.7.7"><a href="#rfc.section.7.7">7.7</a> <a id="DELETE" href="#DELETE">DELETE</a></h2> 1070 <p id="rfc.section.7.7.p.1">The DELETE method requests that the origin server delete the resource identified by the request-target. This method <em class="bcp14">MAY</em> be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation1076 <p id="rfc.section.7.7.p.1">The DELETE method requests that the origin server delete the resource identified by the Effective Request URI. This method <em class="bcp14">MAY</em> be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation 1071 1077 has been carried out, even if the status code returned from the origin server indicates that the action has been completed 1072 1078 successfully. However, the server <em class="bcp14">SHOULD NOT</em> indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible … … 1076 1082 or 204 (No Content) if the action has been enacted but the response does not include an entity. 1077 1083 </p> 1078 <p id="rfc.section.7.7.p.3">If the request passes through a cache and the request-target identifies one or more currently cached entities, those entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to this method are not cacheable. 1084 <p id="rfc.section.7.7.p.3">If the request passes through a cache and the Effective Request URI identifies one or more currently cached entities, those 1085 entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to this method are not cacheable. 1079 1086 </p> 1080 1087 <h2 id="rfc.section.7.8"><a href="#rfc.section.7.8">7.8</a> <a id="TRACE" href="#TRACE">TRACE</a></h2> … … 1086 1093 </p> 1087 1094 <p id="rfc.section.7.8.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 1088 or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 9.9</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>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the1095 or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 9.9</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>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the 1089 1096 client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an 1090 1097 infinite loop. 1091 1098 </p> 1092 <p id="rfc.section.7.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> contain the entire request message in the entity-body, with a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 10.3.1</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>). Responses to this method <em class="bcp14">MUST NOT</em> be cached.1099 <p id="rfc.section.7.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> contain the entire request message in the entity-body, with a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 10.3.1</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>). Responses to this method <em class="bcp14">MUST NOT</em> be cached. 1093 1100 </p> 1094 1101 <div id="rfc.iref.c.1"></div> … … 1117 1124 <p id="rfc.section.8.1.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 1118 1125 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 1119 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 7.2.3</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> for detailed discussion of the use and handling of this status code.1126 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 7.2.3</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> for detailed discussion of the use and handling of this status code. 1120 1127 </p> 1121 1128 <div id="rfc.iref.26"></div> … … 1228 1235 <div id="rfc.iref.s.12"></div> 1229 1236 <h3 id="rfc.section.8.3.2"><a href="#rfc.section.8.3.2">8.3.2</a> <a id="status.301" href="#status.301">301 Moved Permanently</a></h3> 1230 <p id="rfc.section.8.3.2.p.1">The requested resource has been assigned a new permanent URI and any future references to this resource <em class="bcp14">SHOULD</em> use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the request-target 1231 to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise. 1237 <p id="rfc.section.8.3.2.p.1">The requested resource has been assigned a new permanent URI and any future references to this resource <em class="bcp14">SHOULD</em> use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Effective 1238 Request URI to one or more of the new references returned by the server, where possible. This response is cacheable unless 1239 indicated otherwise. 1232 1240 </p> 1233 1241 <p id="rfc.section.8.3.2.p.2">The new permanent URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the entity of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s). … … 1245 1253 <h3 id="rfc.section.8.3.3"><a href="#rfc.section.8.3.3">8.3.3</a> <a id="status.302" href="#status.302">302 Found</a></h3> 1246 1254 <p id="rfc.section.8.3.3.p.1">The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the 1247 client <em class="bcp14">SHOULD</em> continue to use the request-target for future requests. This response is only cacheable if indicated by a Cache-Control or1248 Expires header field.1255 client <em class="bcp14">SHOULD</em> continue to use the Effectice Request URI for future requests. This response is only cacheable if indicated by a Cache-Control 1256 or Expires header field. 1249 1257 </p> 1250 1258 <p id="rfc.section.8.3.3.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the entity of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s). … … 1298 1306 <div id="rfc.iref.s.18"></div> 1299 1307 <h3 id="rfc.section.8.3.8"><a href="#rfc.section.8.3.8">8.3.8</a> <a id="status.307" href="#status.307">307 Temporary Redirect</a></h3> 1300 <p id="rfc.section.8.3.8.p.1">The requested resource resides temporarily under a different URI. Since the redirection <em class="bcp14">MAY</em> be altered on occasion, the client <em class="bcp14">SHOULD</em> continue to use the request-target for future requests. This response is only cacheable if indicated by a Cache-Control or1301 Expires header field.1308 <p id="rfc.section.8.3.8.p.1">The requested resource resides temporarily under a different URI. Since the redirection <em class="bcp14">MAY</em> be altered on occasion, the client <em class="bcp14">SHOULD</em> continue to use the Effective Request URI for future requests. This response is only cacheable if indicated by a Cache-Control 1309 or Expires header field. 1302 1310 </p> 1303 1311 <p id="rfc.section.8.3.8.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the entity of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s) , since many pre-HTTP/1.1 user agents do not understand … … 1341 1349 <div id="rfc.iref.s.23"></div> 1342 1350 <h3 id="rfc.section.8.4.5"><a href="#rfc.section.8.4.5">8.4.5</a> <a id="status.404" href="#status.404">404 Not Found</a></h3> 1343 <p id="rfc.section.8.4.5.p.1">The server has not found anything matching the request-target. No indication is given of whether the condition is temporary1351 <p id="rfc.section.8.4.5.p.1">The server has not found anything matching the Effective Request URI. No indication is given of whether the condition is temporary 1344 1352 or permanent. The 410 (Gone) status code <em class="bcp14">SHOULD</em> be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable 1345 1353 and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request … … 1349 1357 <div id="rfc.iref.s.24"></div> 1350 1358 <h3 id="rfc.section.8.4.6"><a href="#rfc.section.8.4.6">8.4.6</a> <a id="status.405" href="#status.405">405 Method Not Allowed</a></h3> 1351 <p id="rfc.section.8.4.6.p.1">The method specified in the Request-Line is not allowed for the resource identified by the request-target. The response <em class="bcp14">MUST</em> include an Allow header containing a list of valid methods for the requested resource.1359 <p id="rfc.section.8.4.6.p.1">The method specified in the Request-Line is not allowed for the resource identified by the Effective Request URI. The response <em class="bcp14">MUST</em> include an Allow header containing a list of valid methods for the requested resource. 1352 1360 </p> 1353 1361 <div id="rfc.iref.48"></div> … … 1396 1404 <h3 id="rfc.section.8.4.11"><a href="#rfc.section.8.4.11">8.4.11</a> <a id="status.410" href="#status.410">410 Gone</a></h3> 1397 1405 <p id="rfc.section.8.4.11.p.1">The requested resource is no longer available at the server and no forwarding address is known. This condition is expected 1398 to be considered permanent. Clients with link editing capabilities <em class="bcp14">SHOULD</em> delete references to the request-targetafter user approval. If the server does not know, or has no facility to determine,1406 to be considered permanent. Clients with link editing capabilities <em class="bcp14">SHOULD</em> delete references to the Effective Request URI after user approval. If the server does not know, or has no facility to determine, 1399 1407 whether or not the condition is permanent, the status code 404 (Not Found) <em class="bcp14">SHOULD</em> be used instead. This response is cacheable unless indicated otherwise. 1400 1408 </p> … … 1428 1436 <div id="rfc.iref.s.33"></div> 1429 1437 <h3 id="rfc.section.8.4.15"><a href="#rfc.section.8.4.15">8.4.15</a> <a id="status.414" href="#status.414">414 URI Too Long</a></h3> 1430 <p id="rfc.section.8.4.15.p.1">The server is refusing to service the request because the request-targetis longer than the server is willing to interpret.1438 <p id="rfc.section.8.4.15.p.1">The server is refusing to service the request because the Effective Request URI is longer than the server is willing to interpret. 1431 1439 This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long 1432 1440 query information, when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that 1433 1441 points to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present 1434 in some servers using fixed-length buffers for reading or manipulating the request-target.1442 in some servers using fixed-length buffers for reading or manipulating the Effective Request URI. 1435 1443 </p> 1436 1444 <div id="rfc.iref.57"></div> … … 1498 1506 <p id="rfc.section.8.5.6.p.1">The server does not support, or refuses to support, the protocol version that was used in the request message. The server 1499 1507 is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described 1500 in <a href="p1-messaging.html#http.version" title="HTTP Version">Section 2.5</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>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain an entity describing why that version is not supported and what other protocols are supported by that server.1508 in <a href="p1-messaging.html#http.version" title="HTTP Version">Section 2.5</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>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain an entity describing why that version is not supported and what other protocols are supported by that server. 1501 1509 </p> 1502 1510 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> … … 1508 1516 <div id="rfc.iref.h.2"></div> 1509 1517 <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a> <a id="header.allow" href="#header.allow">Allow</a></h2> 1510 <p id="rfc.section.9.1.p.1">The "Allow" response-header field lists the set of methods advertised as supported by the resource identified by the request-target.1511 The purpose of this field is strictly to inform the recipient of valid methods associated with the resource.1518 <p id="rfc.section.9.1.p.1">The "Allow" response-header field lists the set of methods advertised as supported by the resource identified by the Effective 1519 Request URI. The purpose of this field is strictly to inform the recipient of valid methods associated with the resource. 1512 1520 </p> 1513 1521 <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span> <a href="#header.allow" class="smpl">Allow</a> = "Allow" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.allow" class="smpl">Allow-v</a> … … 1543 1551 </p> 1544 1552 <p id="rfc.section.9.2.p.7">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header.</p> 1545 <p id="rfc.section.9.2.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</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> for the use of the 100 (Continue) status.1553 <p id="rfc.section.9.2.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</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> for the use of the 100 (Continue) status. 1546 1554 </p> 1547 1555 <div id="rfc.iref.f.1"></div> … … 1615 1623 <div id="rfc.iref.h.7"></div> 1616 1624 <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a> <a id="header.referer" href="#header.referer">Referer</a></h2> 1617 <p id="rfc.section.9.6.p.1">The "Referer" [sic] request-header field allows the client to specify the URI of the resource from which the request-target1618 was obtained (the "referrer", although the header field is misspelled.).1625 <p id="rfc.section.9.6.p.1">The "Referer" [sic] request-header field allows the client to specify the URI of the resource from which the Effective Request 1626 URI was obtained (the "referrer", although the header field is misspelled.). 1619 1627 </p> 1620 1628 <p id="rfc.section.9.6.p.2">The Referer header allows servers to generate lists of back-links to resources for interest, logging, optimized caching, etc. … … 1623 1631 contain a Referer header field. 1624 1632 </p> 1625 <p id="rfc.section.9.6.p.3">If the request-target was obtained from a source that does not have its own URI (e.g., input from the user keyboard), the1626 Referer field <em class="bcp14">MUST</em> either be sent with the value "about:blank", or not be sent at all. Note that this requirement does not apply to sources with1633 <p id="rfc.section.9.6.p.3">If the Effective Request URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard), 1634 the Referer field <em class="bcp14">MUST</em> either be sent with the value "about:blank", or not be sent at all. Note that this requirement does not apply to sources with 1627 1635 non-HTTP URIs (e.g., FTP). 1628 1636 </p> … … 1631 1639 </pre><p id="rfc.section.9.6.p.5">Example:</p> 1632 1640 <div id="rfc.figure.u.22"></div><pre class="text"> Referer: http://www.example.org/hypertext/Overview.html 1633 </pre><p id="rfc.section.9.6.p.7">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the request-target. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 11.2</a> for security considerations.1641 </pre><p id="rfc.section.9.6.p.7">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the Effective Request URI. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 11.2</a> for security considerations. 1634 1642 </p> 1635 1643 <div id="rfc.iref.r.2"></div> … … 1655 1663 <h2 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a> <a id="header.server" href="#header.server">Server</a></h2> 1656 1664 <p id="rfc.section.9.8.p.1">The "Server" response-header field contains information about the software used by the origin server to handle the request.</p> 1657 <p id="rfc.section.9.8.p.2">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</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>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</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>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for1665 <p id="rfc.section.9.8.p.2">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</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>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</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>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for 1658 1666 identifying the application. 1659 1667 </p> … … 1663 1671 </pre><p id="rfc.section.9.8.p.4">Example:</p> 1664 1672 <div id="rfc.figure.u.27"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 1665 </pre><p id="rfc.section.9.8.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</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>).1673 </pre><p id="rfc.section.9.8.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</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>). 1666 1674 </p> 1667 1675 <div class="note" id="rfc.section.9.8.p.7"> … … 1678 1686 to avoid particular user agent limitations. 1679 1687 </p> 1680 <p id="rfc.section.9.9.p.2">User agents <em class="bcp14">SHOULD</em> include this field with requests. The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</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>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</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>) identifying the agent and any subproducts which form a significant part of the user agent. By convention, the product tokens1688 <p id="rfc.section.9.9.p.2">User agents <em class="bcp14">SHOULD</em> include this field with requests. The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.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>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</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>) identifying the agent and any subproducts which form a significant part of the user agent. By convention, the product tokens 1681 1689 are listed in order of their significance for identifying the application. 1682 1690 </p> … … 2114 2122 </p> 2115 2123 <p id="rfc.section.11.2.p.3">Authors of services should not use GET-based forms for the submission of sensitive data because that data will be encoded 2116 in the Request-target. Many existing servers, proxies, and user agents log or display the Request-target in places where it2124 in the request-target. Many existing servers, proxies, and user agents log or display the request-target in places where it 2117 2125 might be visible to third parties. Such services can use POST-based form submission instead. 2118 2126 </p> … … 2282 2290 </p> 2283 2291 <p id="rfc.section.A.2.p.8">In the description of the Server header, the Via field was described as a SHOULD. The requirement was and is stated correctly 2284 in the description of the Via header in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</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>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 9.8</a>)2292 in the description of the Via header in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</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>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 9.8</a>) 2285 2293 </p> 2286 2294 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> … … 2565 2573 <ul> 2566 2574 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/185">http://tools.ietf.org/wg/httpbis/trac/ticket/185</a>>: "Location header payload handling" 2575 </li> 2576 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/196">http://tools.ietf.org/wg/httpbis/trac/ticket/196</a>>: "Term for the requested resource's URI" 2567 2577 </li> 2568 2578 </ul> … … 2735 2745 </li> 2736 2746 <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"> 2737 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">1</a>, <a class="iref" href="#rfc.xref.Part1.2">1.2</a>, <a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.8">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.9">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.12">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.16">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.17"> 3</a>, <a class="iref" href="#rfc.xref.Part1.18">3</a>, <a class="iref" href="#rfc.xref.Part1.19">6</a>, <a class="iref" href="#rfc.xref.Part1.20">7.8</a>, <a class="iref" href="#rfc.xref.Part1.21">7.8</a>, <a class="iref" href="#rfc.xref.Part1.22">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.23">8.5.6</a>, <a class="iref" href="#rfc.xref.Part1.24">9.2</a>, <a class="iref" href="#rfc.xref.Part1.25">9.8</a>, <a class="iref" href="#rfc.xref.Part1.26">9.8</a>, <a class="iref" href="#rfc.xref.Part1.27">9.8</a>, <a class="iref" href="#rfc.xref.Part1.28">9.9</a>, <a class="iref" href="#rfc.xref.Part1.29">9.9</a>, <a class="iref" href="#Part1"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part1.30">A.2</a><ul class="ind">2747 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">1</a>, <a class="iref" href="#rfc.xref.Part1.2">1.2</a>, <a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.8">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.9">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.12">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.16">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.17">2</a>, <a class="iref" href="#rfc.xref.Part1.18">3</a>, <a class="iref" href="#rfc.xref.Part1.19">3</a>, <a class="iref" href="#rfc.xref.Part1.20">5</a>, <a class="iref" href="#rfc.xref.Part1.21">6</a>, <a class="iref" href="#rfc.xref.Part1.22">6.1</a>, <a class="iref" href="#rfc.xref.Part1.23">7.8</a>, <a class="iref" href="#rfc.xref.Part1.24">7.8</a>, <a class="iref" href="#rfc.xref.Part1.25">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.26">8.5.6</a>, <a class="iref" href="#rfc.xref.Part1.27">9.2</a>, <a class="iref" href="#rfc.xref.Part1.28">9.8</a>, <a class="iref" href="#rfc.xref.Part1.29">9.8</a>, <a class="iref" href="#rfc.xref.Part1.30">9.8</a>, <a class="iref" href="#rfc.xref.Part1.31">9.9</a>, <a class="iref" href="#rfc.xref.Part1.32">9.9</a>, <a class="iref" href="#Part1"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part1.33">A.2</a><ul class="ind"> 2738 2748 <li class="indline1"><em>Section 1.2</em> <a class="iref" href="#rfc.xref.Part1.2">1.2</a></li> 2739 2749 <li class="indline1"><em>Section 1.2.2</em> <a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.8">1.2.1</a></li> 2740 <li class="indline1"><em>Section 2.5</em> <a class="iref" href="#rfc.xref.Part1.2 3">8.5.6</a></li>2750 <li class="indline1"><em>Section 2.5</em> <a class="iref" href="#rfc.xref.Part1.26">8.5.6</a></li> 2741 2751 <li class="indline1"><em>Section 2.6</em> <a class="iref" href="#rfc.xref.Part1.9">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.16">1.2.2</a></li> 2742 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part1.10">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.26">9.8</a>, <a class="iref" href="#rfc.xref.Part1.29">9.9</a></li> 2743 <li class="indline1"><em>Section 3.3</em> <a class="iref" href="#rfc.xref.Part1.19">6</a></li> 2752 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part1.10">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.29">9.8</a>, <a class="iref" href="#rfc.xref.Part1.32">9.9</a></li> 2753 <li class="indline1"><em>Section 3.3</em> <a class="iref" href="#rfc.xref.Part1.21">6</a></li> 2754 <li class="indline1"><em>Section 4.3</em> <a class="iref" href="#rfc.xref.Part1.17">2</a>, <a class="iref" href="#rfc.xref.Part1.20">5</a>, <a class="iref" href="#rfc.xref.Part1.22">6.1</a></li> 2744 2755 <li class="indline1"><em>Section 6.1</em> <a class="iref" href="#rfc.xref.Part1.12">1.2.2</a></li> 2745 <li class="indline1"><em>Section 6.3</em> <a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.2 5">9.8</a>, <a class="iref" href="#rfc.xref.Part1.28">9.9</a></li>2746 <li class="indline1"><em>Section 7.2.3</em> <a class="iref" href="#rfc.xref.Part1.2 2">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.24">9.2</a></li>2747 <li class="indline1"><em>Section 9.4</em> <a class="iref" href="#rfc.xref.Part1.1 7">3</a></li>2748 <li class="indline1"><em>Section 9.8</em> <a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.1 8">3</a></li>2749 <li class="indline1"><em>Section 9.9</em> <a class="iref" href="#rfc.xref.Part1.2 0">7.8</a>, <a class="iref" href="#rfc.xref.Part1.27">9.8</a>, <a class="iref" href="#rfc.xref.Part1.30">A.2</a></li>2750 <li class="indline1"><em>Section 10.3.1</em> <a class="iref" href="#rfc.xref.Part1.2 1">7.8</a></li>2756 <li class="indline1"><em>Section 6.3</em> <a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.28">9.8</a>, <a class="iref" href="#rfc.xref.Part1.31">9.9</a></li> 2757 <li class="indline1"><em>Section 7.2.3</em> <a class="iref" href="#rfc.xref.Part1.25">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.27">9.2</a></li> 2758 <li class="indline1"><em>Section 9.4</em> <a class="iref" href="#rfc.xref.Part1.18">3</a></li> 2759 <li class="indline1"><em>Section 9.8</em> <a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.19">3</a></li> 2760 <li class="indline1"><em>Section 9.9</em> <a class="iref" href="#rfc.xref.Part1.23">7.8</a>, <a class="iref" href="#rfc.xref.Part1.30">9.8</a>, <a class="iref" href="#rfc.xref.Part1.33">A.2</a></li> 2761 <li class="indline1"><em>Section 10.3.1</em> <a class="iref" href="#rfc.xref.Part1.24">7.8</a></li> 2751 2762 </ul> 2752 2763 </li>
Note: See TracChangeset
for help on using the changeset viewer.