Changeset 966 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 30/07/10 06:12:22 (12 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r964 r966 684 684 to each request, in the order received on that connection, with one or more HTTP response messages. This document defines 685 685 the commonly agreed upon semantics of the HTTP uniform interface, the intentions defined by each request method, and the various 686 response messages that might be expected as a result of applying that method for the requestedresource.686 response messages that might be expected as a result of applying that method to the target resource. 687 687 </p> 688 688 <p id="rfc.section.1.p.2">This document is currently disorganized in order to minimize the changes between drafts and enable reviewers to see the smaller … … 726 726 <a href="#abnf.dependencies" class="smpl">TE</a> = <TE, 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#header.te" title="TE">Section 9.5</a>> 727 727 <a href="#abnf.dependencies" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.6</a>> 728 </pre><div id="rfc.figure.u.3"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">Accept</a> = <Accept, defined in <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 5.1</a>>728 </pre><div id="rfc.figure.u.3"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">Accept</a> = <Accept, defined in <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a>> 729 729 <a href="#abnf.dependencies" class="smpl">Accept-Charset</a> = 730 <Accept-Charset, defined in <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 5.2</a>>730 <Accept-Charset, defined in <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 6.2</a>> 731 731 <a href="#abnf.dependencies" class="smpl">Accept-Encoding</a> = 732 <Accept-Encoding, defined in <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 5.3</a>>732 <Accept-Encoding, defined in <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 6.3</a>> 733 733 <a href="#abnf.dependencies" class="smpl">Accept-Language</a> = 734 <Accept-Language, defined in <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 5.4</a>>734 <Accept-Language, defined in <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 6.4</a>> 735 735 </pre><div id="rfc.figure.u.4"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">ETag</a> = <ETag, defined in <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.etag" title="ETag">Section 6.1</a>> 736 736 <a href="#abnf.dependencies" class="smpl">If-Match</a> = <If-Match, defined in <a href="#Part4" id="rfc.xref.Part4.2"><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>> … … 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 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.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 756 </p> 757 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> … … 765 765 / <a href="#method" class="smpl">extension-method</a> 766 766 <a href="#method" class="smpl">extension-method</a> = <a href="#core.rules" class="smpl">token</a> 767 </pre><p id="rfc.section.2.p.3">The list of methods allowed by a resource can be specified in an Allow header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section 9.1</a>). The returncode of the response always notifies the client whether a method is currently allowed on a resource, since the768 set of allowed methods can change dynamically. An origin server <em class="bcp14">SHOULD</em> re turn the status code 405 (Method Not Allowed) if the method is known by the origin server but not allowed for the requested767 </pre><p id="rfc.section.2.p.3">The list of methods allowed by a resource can be specified in an Allow header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section 9.1</a>). The status code of the response always notifies the client whether a method is currently allowed on a resource, since the 768 set of allowed methods can change dynamically. An origin server <em class="bcp14">SHOULD</em> respond with the status code 405 (Method Not Allowed) if the method is known by the origin server but not allowed for the 769 769 resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the origin server. The methods GET 770 770 and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>; however, if the above methods are implemented, they <em class="bcp14">MUST</em> be implemented with the same semantics as those specified in <a href="#method.definitions" title="Method Definitions">Section 7</a>. … … 790 790 method invocation. 791 791 </p> 792 <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.3"></span> <a href="#request.header.fields" class="smpl">request-header</a> = <a href="#abnf.dependencies" class="smpl">Accept</a> ; <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 5.1</a>793 / <a href="#abnf.dependencies" class="smpl">Accept-Charset</a> ; <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 5.2</a>794 / <a href="#abnf.dependencies" class="smpl">Accept-Encoding</a> ; <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 5.3</a>795 / <a href="#abnf.dependencies" class="smpl">Accept-Language</a> ; <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 5.4</a>792 <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.3"></span> <a href="#request.header.fields" class="smpl">request-header</a> = <a href="#abnf.dependencies" class="smpl">Accept</a> ; <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a> 793 / <a href="#abnf.dependencies" class="smpl">Accept-Charset</a> ; <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 6.2</a> 794 / <a href="#abnf.dependencies" class="smpl">Accept-Encoding</a> ; <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 6.3</a> 795 / <a href="#abnf.dependencies" class="smpl">Accept-Language</a> ; <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 6.4</a> 796 796 / <a href="#abnf.dependencies" class="smpl">Authorization</a> ; <a href="#Part7" id="rfc.xref.Part7.5"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.authorization" title="Authorization">Section 3.1</a> 797 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> … … 811 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 812 812 or experimental header fields <em class="bcp14">MAY</em> be given the semantics of request-header fields if all parties in the communication recognize them to be request-header fields. 813 Unrecognized header fields are treated as entity-header fields.814 813 </p> 815 814 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h1> … … 883 882 <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 884 883 Status-Line. These header fields give information about the server and about further access to the resource identified by 885 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>).884 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>). 886 885 </p> 887 886 <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.9"><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> … … 897 896 </pre><p id="rfc.section.5.p.3">Response-header field names can be extended reliably only in combination with a change in the protocol version. However, new 898 897 or experimental header fields <em class="bcp14">MAY</em> be given the semantics of response-header fields if all parties in the communication recognize them to be response-header 899 fields. Unrecognized header fields are treated as entity-header fields.898 fields. 900 899 </p> 901 900 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="representation" href="#representation">Representation</a></h1> … … 908 907 </p> 909 908 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="identifying.response.associated.with.representation" href="#identifying.response.associated.with.representation">Identifying the Resource Associated with a Representation</a></h2> 910 <p id="rfc.section.6.1.p.1">It is sometimes necessary to determine the identity ofthe resource associated with a representation.</p>909 <p id="rfc.section.6.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p> 911 910 <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> 912 <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 following911 <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 913 912 rules are used (with the first applicable one being selected): 914 913 </p> 915 914 <ol> 916 <li>If the response status code is 200 or 203 and the request method was GET, the response is a representation of the resource 917 at the Effective Request URI. 918 </li> 919 <li>If the response status code is 204, 206, or 304 and the request method was GET or HEAD, the response is a partial representation 920 of the resource at the Effective Request URI (see <a href="p6-cache.html#combining.headers" title="Combining Responses">Section 2.8</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 921 </li> 922 <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 923 of the resource at the Effective Request URI. 924 </li> 925 <li>If the response has a Content-Location header, and that URI is not the same as the Effective Request URI, the response asserts 926 that it is a representation of the resource at the Content-Location URI (but it might not be). 915 <li>If the response status code is 200 or 203 and the request method was GET, the response payload is a representation of the 916 resource identified by the effective request URI. 917 </li> 918 <li>If the response status code is 204, 206, or 304 and the request method was GET or HEAD, the response payload is a partial 919 representation of the resource identified by the effective request URI (see <a href="p6-cache.html#combining.headers" title="Combining Responses">Section 2.8</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 920 </li> 921 <li>If the response has a Content-Location header, and that URI is the same as the effective request URI, the response payload 922 is a representation of the resource identified by the effective request URI. 923 </li> 924 <li>If the response has a Content-Location header, and that URI is not the same as the effective request URI, then the response 925 asserts that its payload is a representation of the resource identified by the Content-Location URI. However, such an assertion 926 cannot be trusted unless it can be verified by other means (not defined by HTTP). 927 927 </li> 928 928 <li>Otherwise, the response is a representation of an anonymous (i.e., unidentified) resource.</li> … … 960 960 <div id="rfc.iref.m.1"></div> 961 961 <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 962 chain identified by the Effective Request URI. This method allows the client to determine the options and/or requirements962 chain identified by the effective request URI. This method allows the client to determine the options and/or requirements 963 963 associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval. 964 964 </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 a representation) currently corresponds to the resource 988 identified 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 representation988 identified 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 representation 991 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> … … 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 representation enclosed in the request as data to be 1022 processed by the resource identified by the Effective Request URI. POST is designed to allow a uniform method to cover the1022 processed by the resource identified by the effective request URI. POST is designed to allow a uniform method to cover the 1023 1023 following functions: 1024 1024 </p> … … 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 Effective Request1031 <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 1032 URI. 1033 1033 </p> … … 1039 1039 a Location header (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section 9.4</a>). 1040 1040 </p> 1041 <p id="rfc.section.7.5.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 5.7</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) whose value is the Effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.1041 <p id="rfc.section.7.5.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) whose value is the Effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests. 1042 1042 </p> 1043 1043 <p id="rfc.section.7.5.p.6">Note that POST caching is not widely implemented. However, the 303 (See Other) response can be used to direct the user agent … … 1047 1047 <div id="rfc.iref.m.5"></div> 1048 1048 <h2 id="rfc.section.7.6"><a href="#rfc.section.7.6">7.6</a> <a id="PUT" href="#PUT">PUT</a></h2> 1049 <p id="rfc.section.7.6.p.1">The PUT method requests that the enclosed representation be stored at the Effective Request URI. If the Effective Request1050 URI refers to an already existing resource, the enclosed representation <em class="bcp14">SHOULD</em> be considered a modified version of the one residing on the origin server. Otherwise, if the Effective Request URI does not1049 <p id="rfc.section.7.6.p.1">The PUT method requests that the enclosed representation be stored at the effective request URI. If the effective request 1050 URI refers to an already existing resource, the enclosed representation <em class="bcp14">SHOULD</em> be considered a modified version of the one residing on the origin server. Otherwise, if the effective request URI does not 1051 1051 point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the 1052 1052 origin server can create the resource with that URI. 1053 1053 </p> 1054 <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 (No1054 <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 1055 1055 Content) response codes <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request. 1056 1056 </p> 1057 <p id="rfc.section.7.6.p.3">If the resource identified by the Effective Request URI could not be created or modified, an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the representation <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.1058 </p> 1059 <p id="rfc.section.7.6.p.4">If the request passes through a cache that has one or more stored responses for the Effective Request URI, those stored responses <em class="bcp14">SHOULD</em> be marked as stale if the response to the PUT request has a success status code. Responses to the PUT method are not cacheable.1060 </p> 1061 <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 Request1057 <p id="rfc.section.7.6.p.3">If the resource identified by the effective request URI could not be created or modified, an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the representation <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. 1058 </p> 1059 <p id="rfc.section.7.6.p.4">If the request passes through a cache that has one or more stored responses for the effective request URI, those stored responses <em class="bcp14">SHOULD</em> be marked as stale if the response to the PUT request has a success status code. Responses to the PUT method are not cacheable. 1060 </p> 1061 <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 1062 1062 URI. The URI in a POST request identifies the resource that will handle the enclosed representation. That resource might be 1063 1063 a data-accepting process, a gateway to some other protocol, or a document that accepts annotations. In contrast, the URI in … … 1071 1071 </p> 1072 1072 <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> 1073 <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.1073 <p id="rfc.section.7.6.p.8">Header fields in a PUT request that are recognized as representation metadata <em class="bcp14">SHOULD</em> be applied to the resource created or modified by the PUT. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored. 1074 1074 </p> 1075 1075 <div id="rfc.iref.d.1"></div> 1076 1076 <div id="rfc.iref.m.6"></div> 1077 1077 <h2 id="rfc.section.7.7"><a href="#rfc.section.7.7">7.7</a> <a id="DELETE" href="#DELETE">DELETE</a></h2> 1078 <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 operation1078 <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 1079 1079 has been carried out, even if the status code returned from the origin server indicates that the action has been completed 1080 1080 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 … … 1084 1084 enacted, or 204 (No Content) if the action has been enacted but the response does not include a representation. 1085 1085 </p> 1086 <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 representations,1086 <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 representations, 1087 1087 those entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to the DELETE method are not cacheable. 1088 1088 </p> … … 1143 1143 <div id="rfc.iref.s.4"></div> 1144 1144 <h3 id="rfc.section.8.2.1"><a href="#rfc.section.8.2.1">8.2.1</a> <a id="status.200" href="#status.200">200 OK</a></h3> 1145 <p id="rfc.section.8.2.1.p.1">The request has succeeded. The information returned with the response is dependent on the method used in the request, for 1146 example: 1147 </p> 1145 <p id="rfc.section.8.2.1.p.1">The request has succeeded. The payload returned with the response is dependent on the method used in the request, for example: </p> 1148 1146 <dl> 1149 1147 <dt>GET</dt> 1150 <dd>a representation corresponding to the requested resourceis sent in the response;</dd>1148 <dd>a representation of the resource corresponding to the effective request URI is sent in the response;</dd> 1151 1149 <dt>HEAD</dt> 1152 <dd>the entity-header fields corresponding to the requested resource are sent in the response without anymessage-body;</dd>1150 <dd>the same representation as GET, except without the message-body;</dd> 1153 1151 <dt>POST</dt> 1154 1152 <dd>a representation describing or containing the result of the action;</dd> … … 1185 1183 <div id="rfc.iref.s.7"></div> 1186 1184 <h3 id="rfc.section.8.2.4"><a href="#rfc.section.8.2.4">8.2.4</a> <a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3> 1187 <p id="rfc.section.8.2.4.p.1">The returned metadata in the entity-headeris not the definitive set as available from the origin server, but is gathered1185 <p id="rfc.section.8.2.4.p.1">The returned metadata in the header fields is not the definitive set as available from the origin server, but is gathered 1188 1186 from a local or a third-party copy. The set presented <em class="bcp14">MAY</em> be a subset or superset of the original version. For example, including local annotation information about the resource might 1189 1187 result in a superset of the metadata known by the origin server. Use of this response code is not required and is only appropriate … … 1196 1194 <h3 id="rfc.section.8.2.5"><a href="#rfc.section.8.2.5">8.2.5</a> <a id="status.204" href="#status.204">204 No Content</a></h3> 1197 1195 <p id="rfc.section.8.2.5.p.1">The server has successfully fulfilled the request, but there is no additional content to return in the response payload body. 1198 The resource metadata and representation metadata in the response message's header fields refer to the requested resource1199 and its current representation, respectively, after the requested action. For example, if a 204 status code is received in1200 response to a PUT and the response contains an ETag header field, then the value of that field is the current entity-tag for1201 th e representation that was successfully PUT to the requested resource.1196 The resource metadata and representation metadata in the response message's header fields refer to the target resource and 1197 its current representation, respectively, after the requested action. For example, if a 204 status code is received in response 1198 to a PUT and the response contains an ETag header field, then the value of that field is the current entity-tag for the representation 1199 that was successfully PUT. 1202 1200 </p> 1203 1201 <p id="rfc.section.8.2.5.p.2">If the client is a user agent, it <em class="bcp14">SHOULD NOT</em> change its document view from that which caused the request to be sent. This response is primarily intended to allow input … … 1233 1231 <div id="rfc.iref.s.11"></div> 1234 1232 <h3 id="rfc.section.8.3.1"><a href="#rfc.section.8.3.1">8.3.1</a> <a id="status.300" href="#status.300">300 Multiple Choices</a></h3> 1235 <p id="rfc.section.8.3.1.p.1">The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent-driven1236 negotiation information (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) is being provided so that the user (or user agent) can select a preferred representation and redirectits request to that1233 <p id="rfc.section.8.3.1.p.1">The target resource more than one representation, each with its own specific location, and agent-driven negotiation information 1234 (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to that 1237 1235 location. 1238 1236 </p> 1239 <p id="rfc.section.8.3.1.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include a representation containing a list of re source characteristicsand location(s) from which the user or user agent can1237 <p id="rfc.section.8.3.1.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include a representation containing a list of representation metadata and location(s) from which the user or user agent can 1240 1238 choose the one most appropriate. The data format is specified by the media type given in the Content-Type header field. Depending 1241 1239 upon the format and the capabilities of the user agent, selection of the most appropriate choice <em class="bcp14">MAY</em> be performed automatically. However, this specification does not define any standard for such automatic selection. … … 1248 1246 <div id="rfc.iref.s.12"></div> 1249 1247 <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> 1250 <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 Effective1251 Request URI to one or more of the new references returned by the server, where possible.1248 <p id="rfc.section.8.3.2.p.1">The target 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 1249 request URI to one or more of the new references returned by the server, where possible. 1252 1250 </p> 1253 1251 <p id="rfc.section.8.3.2.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.13"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 301 responses. … … 1266 1264 <div id="rfc.iref.s.13"></div> 1267 1265 <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> 1268 <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 1269 client <em class="bcp14">SHOULD</em> continue to use the Effective Request URI for future requests. 1266 <p id="rfc.section.8.3.3.p.1">The target resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client <em class="bcp14">SHOULD</em> continue to use the effective request URI for future requests. 1270 1267 </p> 1271 1268 <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 representation of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s). … … 1285 1282 <p id="rfc.section.8.3.4.p.1">The server directs the user agent to a different resource, indicated by a URI in the Location header field, that provides 1286 1283 an indirect response to the original request. The user agent <em class="bcp14">MAY</em> perform a GET request on the URI in the Location field in order to obtain a representation corresponding to the response, 1287 be redirected again, or end with an error status. The Location URI is not a substitute reference for the originally requested1288 resource.1284 be redirected again, or end with an error status. The Location URI is not a substitute reference for the effective request 1285 URI. 1289 1286 </p> 1290 1287 <p id="rfc.section.8.3.4.p.2">The 303 status code is generally applicable to any HTTP method. It is primarily used to allow the output of a POST action … … 1293 1290 </p> 1294 1291 <p id="rfc.section.8.3.4.p.3">A 303 response to a GET request indicates that the requested resource does not have a representation of its own that can be 1295 transferred by the server over HTTP. The Location URI indicates a resource that is descriptive of the requested resourcesuch1296 that the follow-on representation might be useful without implying that it adequately represents the previously requested1292 transferred by the server over HTTP. The Location URI indicates a resource that is descriptive of the target resource, such 1293 that the follow-on representation might be useful to recipients without implying that it adequately represents the target 1297 1294 resource. Note that answers to the questions of what can be represented, what representations are adequate, and what might 1298 1295 be a useful description are outside the scope of HTTP and thus entirely determined by the URI owner(s). … … 1318 1315 <div id="rfc.iref.s.18"></div> 1319 1316 <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> 1320 <p id="rfc.section.8.3.8.p.1">The requested resource resides temporarily under a different URI. Since the redirection can change over time, the client <em class="bcp14">SHOULD</em> continue to use the Effective Request URI for future requests.1317 <p id="rfc.section.8.3.8.p.1">The target resource resides temporarily under a different URI. Since the redirection can change over time, the client <em class="bcp14">SHOULD</em> continue to use the effective request URI for future requests. 1321 1318 </p> 1322 1319 <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 representation 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 … … 1360 1357 <div id="rfc.iref.s.23"></div> 1361 1358 <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> 1362 <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 temporary1359 <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 1363 1360 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 1364 1361 and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request … … 1368 1365 <div id="rfc.iref.s.24"></div> 1369 1366 <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> 1370 <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.1367 <p id="rfc.section.8.4.6.p.1">The method specified in the Request-Line is not allowed for the target resource. The response <em class="bcp14">MUST</em> include an Allow header containing a list of valid methods for the requested resource. 1371 1368 </p> 1372 1369 <div id="rfc.iref.48"></div> … … 1414 1411 <div id="rfc.iref.s.29"></div> 1415 1412 <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> 1416 <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 expected1417 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,1413 <p id="rfc.section.8.4.11.p.1">The target resource is no longer available at the server and no forwarding address is known. This condition is expected to 1414 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, 1418 1415 whether or not the condition is permanent, the status code 404 (Not Found) <em class="bcp14">SHOULD</em> be used instead. 1419 1416 </p> … … 1449 1446 <div id="rfc.iref.s.33"></div> 1450 1447 <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> 1451 <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.1448 <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. 1452 1449 This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long 1453 1450 query information, when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that 1454 1451 points to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present 1455 in some servers using fixed-length buffers for reading or manipulating the Effective Request URI.1452 in some servers using fixed-length buffers for reading or manipulating the effective request URI. 1456 1453 </p> 1457 1454 <div id="rfc.iref.57"></div> … … 1459 1456 <h3 id="rfc.section.8.4.16"><a href="#rfc.section.8.4.16">8.4.16</a> <a id="status.415" href="#status.415">415 Unsupported Media Type</a></h3> 1460 1457 <p id="rfc.section.8.4.16.p.1">The server is refusing to service the request because the representation of the request is in a format not supported by the 1461 requestedresource for the requested method.1458 target resource for the requested method. 1462 1459 </p> 1463 1460 <div id="rfc.iref.58"></div> … … 1523 1520 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> 1524 1521 <p id="rfc.section.9.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to request and response semantics.</p> 1525 <p id="rfc.section.9.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who1526 receives the message.1527 </p>1528 1522 <div id="rfc.iref.a.1"></div> 1529 1523 <div id="rfc.iref.h.2"></div> 1530 1524 <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> 1531 <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 Effective1532 Request URI. The purpose ofthis field is strictly to inform the recipient of valid methods associated with the resource.1525 <p id="rfc.section.9.1.p.1">The "Allow" response-header field lists the set of methods advertised as supported by the target resource. The purpose of 1526 this field is strictly to inform the recipient of valid methods associated with the resource. 1533 1527 </p> 1534 1528 <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> … … 1615 1609 </div> 1616 1610 <div class="note" id="rfc.section.9.4.p.9"> 1617 <p> <b>Note:</b> The Content-Location header field (<a href="p3-payload.html#header.content-location" title="Content-Location">Section 5.7</a> of <a href="#Part3" id="rfc.xref.Part3.12"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation.1611 <p> <b>Note:</b> The Content-Location header field (<a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.12"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation. 1618 1612 It is therefore possible for a response to contain header fields for both Location and Content-Location. 1619 1613 </p> … … 1636 1630 <div id="rfc.iref.h.7"></div> 1637 1631 <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> 1638 <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 Request1632 <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 1639 1633 URI was obtained (the "referrer", although the header field is misspelled.). 1640 1634 </p> … … 1644 1638 contain a Referer header field. 1645 1639 </p> 1646 <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),1640 <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), 1647 1641 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 1648 1642 non-HTTP URIs (e.g., FTP). … … 1652 1646 </pre><p id="rfc.section.9.6.p.5">Example:</p> 1653 1647 <div id="rfc.figure.u.22"></div><pre class="text"> Referer: http://www.example.org/hypertext/Overview.html 1654 </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.1648 </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. 1655 1649 </p> 1656 1650 <div id="rfc.iref.r.2"></div> … … 2259 2253 user agent is able to make that determination based on the request method semantics. (Sections <a href="#status.301" id="rfc.xref.status.301.3" title="301 Moved Permanently">8.3.2</a>, <a href="#status.302" id="rfc.xref.status.302.3" title="302 Found">8.3.3</a> and <a href="#status.307" id="rfc.xref.status.307.4" title="307 Temporary Redirect">8.3.8</a>) 2260 2254 </p> 2261 <p id="rfc.section.A.p.4">Deprecate 305 Use Proxy status code, because user agents did not implement it. It used to indicate that the requestedresource2255 <p id="rfc.section.A.p.4">Deprecate 305 Use Proxy status code, because user agents did not implement it. It used to indicate that the target resource 2262 2256 must be accessed through the proxy given by the Location field. The Location field gave the URI of the proxy. The recipient 2263 2257 was expected to repeat this single request via the proxy. (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section 8.3.6</a>) … … 2759 2753 </li> 2760 2754 <li class="indline1"><em>Part3</em> <a class="iref" href="#rfc.xref.Part3.1">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.3">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.4">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.5">3</a>, <a class="iref" href="#rfc.xref.Part3.6">3</a>, <a class="iref" href="#rfc.xref.Part3.7">3</a>, <a class="iref" href="#rfc.xref.Part3.8">3</a>, <a class="iref" href="#rfc.xref.Part3.9">6</a>, <a class="iref" href="#rfc.xref.Part3.10">7.5</a>, <a class="iref" href="#rfc.xref.Part3.11">8.3.1</a>, <a class="iref" href="#rfc.xref.Part3.12">9.4</a>, <a class="iref" href="#Part3"><b>13.1</b></a><ul class="ind"> 2761 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part3.11">8.3.1</a></li>2762 <li class="indline1"><em>Section 5.1</em> <a class="iref" href="#rfc.xref.Part3.1">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.5">3</a></li>2763 <li class="indline1"><em>Section 5.2</em> <a class="iref" href="#rfc.xref.Part3.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.6">3</a></li>2764 <li class="indline1"><em>Section 5.3</em> <a class="iref" href="#rfc.xref.Part3.3">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.7">3</a></li>2765 <li class="indline1"><em>Section 5.4</em> <a class="iref" href="#rfc.xref.Part3.4">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.8">3</a></li>2766 <li class="indline1"><em>Section 5.7</em> <a class="iref" href="#rfc.xref.Part3.10">7.5</a>, <a class="iref" href="#rfc.xref.Part3.12">9.4</a></li>2755 <li class="indline1"><em>Section 5</em> <a class="iref" href="#rfc.xref.Part3.11">8.3.1</a></li> 2756 <li class="indline1"><em>Section 6.1</em> <a class="iref" href="#rfc.xref.Part3.1">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.5">3</a></li> 2757 <li class="indline1"><em>Section 6.2</em> <a class="iref" href="#rfc.xref.Part3.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.6">3</a></li> 2758 <li class="indline1"><em>Section 6.3</em> <a class="iref" href="#rfc.xref.Part3.3">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.7">3</a></li> 2759 <li class="indline1"><em>Section 6.4</em> <a class="iref" href="#rfc.xref.Part3.4">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.8">3</a></li> 2760 <li class="indline1"><em>Section 6.7</em> <a class="iref" href="#rfc.xref.Part3.10">7.5</a>, <a class="iref" href="#rfc.xref.Part3.12">9.4</a></li> 2767 2761 </ul> 2768 2762 </li>
Note: See TracChangeset
for help on using the changeset viewer.