![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 1850
- Timestamp:
- 02/09/12 06:17:24 (9 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
-
p2-semantics.html (modified) (35 diffs)
-
p2-semantics.xml (modified) (3 diffs)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1849 r1850 601 601 </li> 602 602 <li><a href="#rfc.section.4.3">4.3</a> <a href="#method.definitions">Method Definitions</a><ul> 603 <li><a href="#rfc.section.4.3.1">4.3.1</a> <a href="# OPTIONS">OPTIONS</a></li>604 <li><a href="#rfc.section.4.3.2">4.3.2</a> <a href="# GET">GET</a></li>605 <li><a href="#rfc.section.4.3.3">4.3.3</a> <a href="# HEAD">HEAD</a></li>606 <li><a href="#rfc.section.4.3.4">4.3.4</a> <a href="#P OST">POST</a></li>607 <li><a href="#rfc.section.4.3.5">4.3.5</a> <a href="# PUT">PUT</a></li>608 <li><a href="#rfc.section.4.3.6">4.3.6</a> <a href="# DELETE">DELETE</a></li>609 <li><a href="#rfc.section.4.3.7">4.3.7</a> <a href="# TRACE">TRACE</a></li>610 <li><a href="#rfc.section.4.3.8">4.3.8</a> <a href="# CONNECT">CONNECT</a></li>603 <li><a href="#rfc.section.4.3.1">4.3.1</a> <a href="#GET">GET</a></li> 604 <li><a href="#rfc.section.4.3.2">4.3.2</a> <a href="#HEAD">HEAD</a></li> 605 <li><a href="#rfc.section.4.3.3">4.3.3</a> <a href="#POST">POST</a></li> 606 <li><a href="#rfc.section.4.3.4">4.3.4</a> <a href="#PUT">PUT</a></li> 607 <li><a href="#rfc.section.4.3.5">4.3.5</a> <a href="#DELETE">DELETE</a></li> 608 <li><a href="#rfc.section.4.3.6">4.3.6</a> <a href="#CONNECT">CONNECT</a></li> 609 <li><a href="#rfc.section.4.3.7">4.3.7</a> <a href="#OPTIONS">OPTIONS</a></li> 610 <li><a href="#rfc.section.4.3.8">4.3.8</a> <a href="#TRACE">TRACE</a></li> 611 611 </ul> 612 612 </li> … … 1016 1016 <td class="left">GET</td> 1017 1017 <td class="left">Transfer a current representation of the target resource.</td> 1018 <td class="left"><a href="#GET" id="rfc.xref.GET.1" title="GET">4.3. 2</a></td>1018 <td class="left"><a href="#GET" id="rfc.xref.GET.1" title="GET">4.3.1</a></td> 1019 1019 </tr> 1020 1020 <tr> 1021 1021 <td class="left">HEAD</td> 1022 1022 <td class="left">Same as GET, but do not include a message body in the response.</td> 1023 <td class="left"><a href="#HEAD" id="rfc.xref.HEAD.1" title="HEAD">4.3. 3</a></td>1023 <td class="left"><a href="#HEAD" id="rfc.xref.HEAD.1" title="HEAD">4.3.2</a></td> 1024 1024 </tr> 1025 1025 <tr> 1026 1026 <td class="left">POST</td> 1027 1027 <td class="left">Perform resource-specific processing on the request payload.</td> 1028 <td class="left"><a href="#POST" id="rfc.xref.POST.1" title="POST">4.3. 4</a></td>1028 <td class="left"><a href="#POST" id="rfc.xref.POST.1" title="POST">4.3.3</a></td> 1029 1029 </tr> 1030 1030 <tr> 1031 1031 <td class="left">PUT</td> 1032 1032 <td class="left">Replace all current representations of the target resource with the request payload.</td> 1033 <td class="left"><a href="#PUT" id="rfc.xref.PUT.1" title="PUT">4.3. 5</a></td>1033 <td class="left"><a href="#PUT" id="rfc.xref.PUT.1" title="PUT">4.3.4</a></td> 1034 1034 </tr> 1035 1035 <tr> 1036 1036 <td class="left">DELETE</td> 1037 1037 <td class="left">Remove all current representations of the target resource.</td> 1038 <td class="left"><a href="#DELETE" id="rfc.xref.DELETE.1" title="DELETE">4.3. 6</a></td>1038 <td class="left"><a href="#DELETE" id="rfc.xref.DELETE.1" title="DELETE">4.3.5</a></td> 1039 1039 </tr> 1040 1040 <tr> 1041 1041 <td class="left">CONNECT</td> 1042 1042 <td class="left">Establish a tunnel to the server identified by the target resource.</td> 1043 <td class="left"><a href="#CONNECT" id="rfc.xref.CONNECT.1" title="CONNECT">4.3. 8</a></td>1043 <td class="left"><a href="#CONNECT" id="rfc.xref.CONNECT.1" title="CONNECT">4.3.6</a></td> 1044 1044 </tr> 1045 1045 <tr> 1046 1046 <td class="left">OPTIONS</td> 1047 1047 <td class="left">Describe the communication options for the target resource.</td> 1048 <td class="left"><a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">4.3. 1</a></td>1048 <td class="left"><a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">4.3.7</a></td> 1049 1049 </tr> 1050 1050 <tr> 1051 1051 <td class="left">TRACE</td> 1052 1052 <td class="left">Perform a message loop-back test along the path to the target resource.</td> 1053 <td class="left"><a href="#TRACE" id="rfc.xref.TRACE.1" title="TRACE">4.3. 7</a></td>1053 <td class="left"><a href="#TRACE" id="rfc.xref.TRACE.1" title="TRACE">4.3.8</a></td> 1054 1054 </tr> 1055 1055 </tbody> … … 1117 1117 </p> 1118 1118 <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a> <a id="method.definitions" href="#method.definitions">Method Definitions</a></h2> 1119 <h3 id="rfc.section.4.3.1"><a href="#rfc.section.4.3.1">4.3.1</a> <a id=" OPTIONS" href="#OPTIONS">OPTIONS</a></h3>1120 <div id="rfc.iref. o.1"></div>1119 <h3 id="rfc.section.4.3.1"><a href="#rfc.section.4.3.1">4.3.1</a> <a id="GET" href="#GET">GET</a></h3> 1120 <div id="rfc.iref.g.2"></div> 1121 1121 <div id="rfc.iref.m.1"></div> 1122 <p id="rfc.section.4.3.1.p.1">The OPTIONS method requests information about the communication options available on the request/response chain identified 1123 by the effective request URI. This method allows a client to determine the options and/or requirements associated with a resource, 1124 or the capabilities of a server, without implying a resource action or initiating a resource retrieval. 1125 </p> 1126 <p id="rfc.section.4.3.1.p.2">Responses to the OPTIONS method are not cacheable.</p> 1127 <p id="rfc.section.4.3.1.p.3">If the OPTIONS request includes a message body (as indicated by the presence of <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> or <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a>), then the media type <em class="bcp14">MUST</em> be indicated by a <a href="#header.content-type" class="smpl">Content-Type</a> field. Although this specification does not define any use for such a body, future extensions to HTTP might use the OPTIONS 1128 body to make more detailed queries on the server. 1129 </p> 1130 <p id="rfc.section.4.3.1.p.4">If the request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>) is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource. 1131 Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" 1132 type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be 1133 used to test a proxy for HTTP/1.1 conformance (or lack thereof). 1134 </p> 1135 <p id="rfc.section.4.3.1.p.5">If the request-target is not an asterisk, the OPTIONS request applies only to the options that are available when communicating 1136 with that resource. 1137 </p> 1138 <p id="rfc.section.4.3.1.p.6">A <a href="#status.200" class="smpl">200 (OK)</a> response <em class="bcp14">SHOULD</em> include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., <a href="#header.allow" class="smpl">Allow</a>), possibly including extensions not defined by this specification. The response body, if any, <em class="bcp14">SHOULD</em> also include information about the communication options. The format for such a body is not defined by this specification, 1139 but might be defined by future extensions to HTTP. Content negotiation <em class="bcp14">MAY</em> be used to select the appropriate response format. If no response body is included, the response <em class="bcp14">MUST</em> include a <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> field with a field-value of "0". 1140 </p> 1141 <p id="rfc.section.4.3.1.p.7">The <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section 10.14</a>). If no Max-Forwards field is present in the request, then the forwarded request <em class="bcp14">MUST NOT</em> include a Max-Forwards field. 1142 </p> 1143 <h3 id="rfc.section.4.3.2"><a href="#rfc.section.4.3.2">4.3.2</a> <a id="GET" href="#GET">GET</a></h3> 1144 <div id="rfc.iref.g.2"></div> 1145 <div id="rfc.iref.m.2"></div> 1146 <p id="rfc.section.4.3.2.p.1">The GET method requests transfer of a current representation of the target resource.</p> 1147 <p id="rfc.section.4.3.2.p.2">If the target resource is a data-producing process, it is the produced data which shall be returned as the representation 1122 <p id="rfc.section.4.3.1.p.1">The GET method requests transfer of a current representation of the target resource.</p> 1123 <p id="rfc.section.4.3.1.p.2">If the target resource is a data-producing process, it is the produced data which shall be returned as the representation 1148 1124 in the response and not the source text of the process, unless that text happens to be the output of the process. 1149 1125 </p> 1150 <p id="rfc.section.4.3. 2.p.3">The semantics of the GET method change to a "conditional GET" if the request message includes an <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a>, <a href="p4-conditional.html#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a>, <a href="p4-conditional.html#header.if-match" class="smpl">If-Match</a>, <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a>, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field (<a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). A conditional GET requests that the representation be transferred only under the circumstances described by the conditional1126 <p id="rfc.section.4.3.1.p.3">The semantics of the GET method change to a "conditional GET" if the request message includes an <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a>, <a href="p4-conditional.html#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a>, <a href="p4-conditional.html#header.if-match" class="smpl">If-Match</a>, <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a>, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field (<a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). A conditional GET requests that the representation be transferred only under the circumstances described by the conditional 1151 1127 header field(s). The conditional GET request is intended to reduce unnecessary network usage by allowing cached representations 1152 1128 to be refreshed without requiring multiple requests or transferring data already held by the client. 1153 1129 </p> 1154 <p id="rfc.section.4.3. 2.p.4">The semantics of the GET method change to a "partial GET" if the request message includes a <a href="p5-range.html#range.retrieval.requests" class="smpl">Range</a> header field (<a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a>). A partial GET requests that only part of the representation be transferred, as described in <a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a>. The partial GET request is intended to reduce unnecessary network usage by allowing partially-retrieved representations1130 <p id="rfc.section.4.3.1.p.4">The semantics of the GET method change to a "partial GET" if the request message includes a <a href="p5-range.html#range.retrieval.requests" class="smpl">Range</a> header field (<a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a>). A partial GET requests that only part of the representation be transferred, as described in <a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a>. The partial GET request is intended to reduce unnecessary network usage by allowing partially-retrieved representations 1155 1131 to be completed without transferring data already held by the client. 1156 1132 </p> 1157 <p id="rfc.section.4.3. 2.p.5">Bodies on GET requests have no defined semantics. Note that sending a body on a GET request might cause some existing implementations1133 <p id="rfc.section.4.3.1.p.5">Bodies on GET requests have no defined semantics. Note that sending a body on a GET request might cause some existing implementations 1158 1134 to reject the request. 1159 1135 </p> 1160 <p id="rfc.section.4.3. 2.p.6">The response to a GET request is cacheable and <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests (see <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).1161 </p> 1162 <p id="rfc.section.4.3. 2.p.7">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 12.2</a> for security considerations when used for forms.1163 </p> 1164 <h3 id="rfc.section.4.3. 3"><a href="#rfc.section.4.3.3">4.3.3</a> <a id="HEAD" href="#HEAD">HEAD</a></h3>1136 <p id="rfc.section.4.3.1.p.6">The response to a GET request is cacheable and <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests (see <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1137 </p> 1138 <p id="rfc.section.4.3.1.p.7">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 12.2</a> for security considerations when used for forms. 1139 </p> 1140 <h3 id="rfc.section.4.3.2"><a href="#rfc.section.4.3.2">4.3.2</a> <a id="HEAD" href="#HEAD">HEAD</a></h3> 1165 1141 <div id="rfc.iref.h.1"></div> 1166 <div id="rfc.iref.m. 3"></div>1167 <p id="rfc.section.4.3. 3.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> return a message body in the response. The metadata contained in the HTTP header fields in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metadata about the1142 <div id="rfc.iref.m.2"></div> 1143 <p id="rfc.section.4.3.2.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> return a message body in the response. The metadata contained in the HTTP header fields in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metadata about the 1168 1144 representation implied by the request without transferring the representation body. This method is often used for testing 1169 1145 hypertext links for validity, accessibility, and recent modification. 1170 1146 </p> 1171 <p id="rfc.section.4.3. 3.p.2">The response to a HEAD request is cacheable and <em class="bcp14">MAY</em> be used to satisfy a subsequent HEAD request. It also has potential side effects on previously stored responses to GET; see <a href="p6-cache.html#head.effects" title="Updating Caches with HEAD Responses">Section 5</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.1172 </p> 1173 <p id="rfc.section.4.3. 3.p.3">Bodies on HEAD requests have no defined semantics. Note that sending a body on a HEAD request might cause some existing implementations1147 <p id="rfc.section.4.3.2.p.2">The response to a HEAD request is cacheable and <em class="bcp14">MAY</em> be used to satisfy a subsequent HEAD request. It also has potential side effects on previously stored responses to GET; see <a href="p6-cache.html#head.effects" title="Updating Caches with HEAD Responses">Section 5</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 1148 </p> 1149 <p id="rfc.section.4.3.2.p.3">Bodies on HEAD requests have no defined semantics. Note that sending a body on a HEAD request might cause some existing implementations 1174 1150 to reject the request. 1175 1151 </p> 1176 1152 <div id="rfc.iref.p.1"></div> 1177 <div id="rfc.iref.m. 4"></div>1178 <h3 id="rfc.section.4.3. 4"><a href="#rfc.section.4.3.4">4.3.4</a> <a id="POST" href="#POST">POST</a></h3>1179 <p id="rfc.section.4.3. 4.p.1">The POST method requests that the origin server accept the representation enclosed in the request as data to be processed1153 <div id="rfc.iref.m.3"></div> 1154 <h3 id="rfc.section.4.3.3"><a href="#rfc.section.4.3.3">4.3.3</a> <a id="POST" href="#POST">POST</a></h3> 1155 <p id="rfc.section.4.3.3.p.1">The POST method requests that the origin server accept the representation enclosed in the request as data to be processed 1180 1156 by the target resource. POST is designed to allow a uniform method to cover the following functions: 1181 1157 </p> … … 1186 1162 <li>Extending a database through an append operation.</li> 1187 1163 </ul> 1188 <p id="rfc.section.4.3. 4.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the effective request1164 <p id="rfc.section.4.3.3.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the effective request 1189 1165 URI. 1190 1166 </p> 1191 <p id="rfc.section.4.3. 4.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 <a href="#status.200" class="smpl">200 (OK)</a> or <a href="#status.204" class="smpl">204 (No Content)</a> is the appropriate response status code, depending on whether or not the response includes a representation that describes1167 <p id="rfc.section.4.3.3.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 <a href="#status.200" class="smpl">200 (OK)</a> or <a href="#status.204" class="smpl">204 (No Content)</a> is the appropriate response status code, depending on whether or not the response includes a representation that describes 1192 1168 the result. 1193 1169 </p> 1194 <p id="rfc.section.4.3. 4.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be <a href="#status.201" class="smpl">201 (Created)</a> and contain a representation which describes the status of the request and refers to the new resource, and a <a href="#header.location" class="smpl">Location</a> header field (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 10.13</a>).1195 </p> 1196 <p id="rfc.section.4.3. 4.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 4.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a <a href="#header.content-location" class="smpl">Content-Location</a> header field (see <a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section 10.8</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.1197 </p> 1198 <p id="rfc.section.4.3. 4.p.6">Note that POST caching is not widely implemented. However, the <a href="#status.303" class="smpl">303 (See Other)</a> response can be used to direct the user agent to retrieve a cacheable representation of the resource.1199 </p> 1200 <h3 id="rfc.section.4.3. 5"><a href="#rfc.section.4.3.5">4.3.5</a> <a id="PUT" href="#PUT">PUT</a></h3>1170 <p id="rfc.section.4.3.3.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be <a href="#status.201" class="smpl">201 (Created)</a> and contain a representation which describes the status of the request and refers to the new resource, and a <a href="#header.location" class="smpl">Location</a> header field (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 10.13</a>). 1171 </p> 1172 <p id="rfc.section.4.3.3.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 4.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a <a href="#header.content-location" class="smpl">Content-Location</a> header field (see <a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section 10.8</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests. 1173 </p> 1174 <p id="rfc.section.4.3.3.p.6">Note that POST caching is not widely implemented. However, the <a href="#status.303" class="smpl">303 (See Other)</a> response can be used to direct the user agent to retrieve a cacheable representation of the resource. 1175 </p> 1176 <h3 id="rfc.section.4.3.4"><a href="#rfc.section.4.3.4">4.3.4</a> <a id="PUT" href="#PUT">PUT</a></h3> 1201 1177 <div id="rfc.iref.p.2"></div> 1202 <div id="rfc.iref.m. 5"></div>1203 <p id="rfc.section.4.3. 5.p.1">The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation1178 <div id="rfc.iref.m.4"></div> 1179 <p id="rfc.section.4.3.4.p.1">The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation 1204 1180 enclosed in the request message payload. A successful PUT of a given representation would suggest that a subsequent GET on 1205 1181 that same target resource will result in an equivalent representation being returned in a <a href="#status.200" class="smpl">200 (OK)</a> response. However, there is no guarantee that such a state change will be observable, since the target resource might be acted … … 1208 1184 by the origin server. 1209 1185 </p> 1210 <p id="rfc.section.4.3. 5.p.2">If the target resource does not have a current representation and the PUT successfully creates one, then the origin server <em class="bcp14">MUST</em> inform the user agent by sending a <a href="#status.201" class="smpl">201 (Created)</a> response. If the target resource does have a current representation and that representation is successfully modified in accordance1186 <p id="rfc.section.4.3.4.p.2">If the target resource does not have a current representation and the PUT successfully creates one, then the origin server <em class="bcp14">MUST</em> inform the user agent by sending a <a href="#status.201" class="smpl">201 (Created)</a> response. If the target resource does have a current representation and that representation is successfully modified in accordance 1211 1187 with the state of the enclosed representation, then either a <a href="#status.200" class="smpl">200 (OK)</a> or <a href="#status.204" class="smpl">204 (No Content)</a> response <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request. 1212 1188 </p> 1213 <p id="rfc.section.4.3. 5.p.3">Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored (i.e., not saved as part of the resource state).1214 </p> 1215 <p id="rfc.section.4.3. 5.p.4">An origin server <em class="bcp14">SHOULD</em> verify that the PUT representation is consistent with any constraints which the server has for the target resource that cannot1189 <p id="rfc.section.4.3.4.p.3">Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored (i.e., not saved as part of the resource state). 1190 </p> 1191 <p id="rfc.section.4.3.4.p.4">An origin server <em class="bcp14">SHOULD</em> verify that the PUT representation is consistent with any constraints which the server has for the target resource that cannot 1216 1192 or will not be changed by the PUT. This is particularly important when the origin server uses internal configuration information 1217 1193 related to the URI in order to set the values for representation metadata on GET responses. When a PUT representation is inconsistent … … 1219 1195 appropriate error message containing sufficient information to explain why the representation is unsuitable. The <a href="#status.409" class="smpl">409 (Conflict)</a> or <a href="#status.415" class="smpl">415 (Unsupported Media Type)</a> status codes are suggested, with the latter being specific to constraints on <a href="#header.content-type" class="smpl">Content-Type</a> values. 1220 1196 </p> 1221 <p id="rfc.section.4.3. 5.p.5">For example, if the target resource is configured to always have a <a href="#header.content-type" class="smpl">Content-Type</a> of "text/html" and the representation being PUT has a Content-Type of "image/jpeg", then the origin server <em class="bcp14">SHOULD</em> do one of:1197 <p id="rfc.section.4.3.4.p.5">For example, if the target resource is configured to always have a <a href="#header.content-type" class="smpl">Content-Type</a> of "text/html" and the representation being PUT has a Content-Type of "image/jpeg", then the origin server <em class="bcp14">SHOULD</em> do one of: 1222 1198 </p> 1223 1199 <ol class="la"> … … 1230 1206 </li> 1231 1207 </ol> 1232 <p id="rfc.section.4.3. 5.p.6">HTTP does not define exactly how a PUT method affects the state of an origin server beyond what can be expressed by the intent1208 <p id="rfc.section.4.3.4.p.6">HTTP does not define exactly how a PUT method affects the state of an origin server beyond what can be expressed by the intent 1233 1209 of the user agent request and the semantics of the origin server response. It does not define what a resource might be, in 1234 1210 any sense of that word, beyond the interface provided via HTTP. It does not define how resource state is "stored", nor how … … 1237 1213 the server. 1238 1214 </p> 1239 <p id="rfc.section.4.3. 5.p.7">The fundamental difference between the POST and PUT methods is highlighted by the different intent for the target resource.1215 <p id="rfc.section.4.3.4.p.7">The fundamental difference between the POST and PUT methods is highlighted by the different intent for the target resource. 1240 1216 The target resource in a POST request is intended to handle the enclosed representation as a data-accepting process, such 1241 1217 as for a gateway to some other protocol or a document that accepts annotations. In contrast, the target resource in a PUT … … 1243 1219 and visible to intermediaries, even though the exact effect is only known by the origin server. 1244 1220 </p> 1245 <p id="rfc.section.4.3. 5.p.8">Proper interpretation of a PUT request presumes that the user agent knows what target resource is desired. A service that1221 <p id="rfc.section.4.3.4.p.8">Proper interpretation of a PUT request presumes that the user agent knows what target resource is desired. A service that 1246 1222 is intended to select a proper URI on behalf of the client, after receiving a state-changing request, <em class="bcp14">SHOULD</em> be implemented using the POST method rather than PUT. If the origin server will not make the requested PUT state change to 1247 1223 the target resource and instead wishes to have it applied to a different resource, such as when the resource has been moved 1248 1224 to a different URI, then the origin server <em class="bcp14">MUST</em> send a <a href="#status.301" class="smpl">301 (Moved Permanently)</a> response; the user agent <em class="bcp14">MAY</em> then make its own decision regarding whether or not to redirect the request. 1249 1225 </p> 1250 <p id="rfc.section.4.3. 5.p.9">A PUT request applied to the target resource <em class="bcp14">MAY</em> have side-effects on other resources. For example, an article might have a URI for identifying "the current version" (a resource)1226 <p id="rfc.section.4.3.4.p.9">A PUT request applied to the target resource <em class="bcp14">MAY</em> have side-effects on other resources. For example, an article might have a URI for identifying "the current version" (a resource) 1251 1227 which is separate from the URIs identifying each particular version (different resources that at one point shared the same 1252 1228 state as the current version resource). A successful PUT request on "the current version" URI might therefore create a new … … 1254 1230 the related resources. 1255 1231 </p> 1256 <p id="rfc.section.4.3. 5.p.10">An origin server <em class="bcp14">SHOULD</em> reject any PUT request that contains a <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> header field (<a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a>), since it might be misinterpreted as partial content (or might be partial content that is being mistakenly PUT as a full1232 <p id="rfc.section.4.3.4.p.10">An origin server <em class="bcp14">SHOULD</em> reject any PUT request that contains a <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> header field (<a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a>), since it might be misinterpreted as partial content (or might be partial content that is being mistakenly PUT as a full 1257 1233 representation). Partial content updates are possible by targeting a separately identified resource with state that overlaps 1258 1234 a portion of the larger resource, or by using a different method that has been specifically defined for partial updates (for 1259 1235 example, the PATCH method defined in <a href="#RFC5789" id="rfc.xref.RFC5789.1"><cite title="PATCH Method for HTTP">[RFC5789]</cite></a>). 1260 1236 </p> 1261 <p id="rfc.section.4.3. 5.p.11">Responses to the PUT method are not cacheable. If a PUT request passes through a cache that has one or more stored responses1237 <p id="rfc.section.4.3.4.p.11">Responses to the PUT method are not cacheable. If a PUT request passes through a cache that has one or more stored responses 1262 1238 for the effective request URI, those stored responses will be invalidated (see <a href="p6-cache.html#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 6</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1263 1239 </p> 1264 <h3 id="rfc.section.4.3. 6"><a href="#rfc.section.4.3.6">4.3.6</a> <a id="DELETE" href="#DELETE">DELETE</a></h3>1240 <h3 id="rfc.section.4.3.5"><a href="#rfc.section.4.3.5">4.3.5</a> <a id="DELETE" href="#DELETE">DELETE</a></h3> 1265 1241 <div id="rfc.iref.d.1"></div> 1266 <div id="rfc.iref.m. 6"></div>1267 <p id="rfc.section.4.3. 6.p.1">The DELETE method requests that the origin server delete the target resource. 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 operation1242 <div id="rfc.iref.m.5"></div> 1243 <p id="rfc.section.4.3.5.p.1">The DELETE method requests that the origin server delete the target resource. 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 1268 1244 has been carried out, even if the status code returned from the origin server indicates that the action has been completed 1269 1245 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 1270 1246 location. 1271 1247 </p> 1272 <p id="rfc.section.4.3. 6.p.2">A successful response <em class="bcp14">SHOULD</em> be <a href="#status.200" class="smpl">200 (OK)</a> if the response includes a representation describing the status, <a href="#status.202" class="smpl">202 (Accepted)</a> if the action has not yet been enacted, or <a href="#status.204" class="smpl">204 (No Content)</a> if the action has been enacted but the response does not include a representation.1273 </p> 1274 <p id="rfc.section.4.3. 6.p.3">Bodies on DELETE requests have no defined semantics. Note that sending a body on a DELETE request might cause some existing1248 <p id="rfc.section.4.3.5.p.2">A successful response <em class="bcp14">SHOULD</em> be <a href="#status.200" class="smpl">200 (OK)</a> if the response includes a representation describing the status, <a href="#status.202" class="smpl">202 (Accepted)</a> if the action has not yet been enacted, or <a href="#status.204" class="smpl">204 (No Content)</a> if the action has been enacted but the response does not include a representation. 1249 </p> 1250 <p id="rfc.section.4.3.5.p.3">Bodies on DELETE requests have no defined semantics. Note that sending a body on a DELETE request might cause some existing 1275 1251 implementations to reject the request. 1276 1252 </p> 1277 <p id="rfc.section.4.3. 6.p.4">Responses to the DELETE method are not cacheable. If a DELETE request passes through a cache that has one or more stored responses1253 <p id="rfc.section.4.3.5.p.4">Responses to the DELETE method are not cacheable. If a DELETE request passes through a cache that has one or more stored responses 1278 1254 for the effective request URI, those stored responses will be invalidated (see <a href="p6-cache.html#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 6</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1279 1255 </p> 1280 <h3 id="rfc.section.4.3.7"><a href="#rfc.section.4.3.7">4.3.7</a> <a id="TRACE" href="#TRACE">TRACE</a></h3>1281 <div id="rfc.iref.t.1"></div>1282 <div id="rfc.iref.m.7"></div>1283 <p id="rfc.section.4.3.7.p.1">The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message body of a <a href="#status.200" class="smpl">200 (OK)</a> response. The final recipient is either the origin server or the first proxy to receive a <a href="#header.max-forwards" class="smpl">Max-Forwards</a> value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section 10.14</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body.1284 </p>1285 <p id="rfc.section.4.3.7.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing1286 or diagnostic information. The value of the <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field (<a href="p1-messaging.html#header.via" title="Via">Section 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding1287 messages in an infinite loop.1288 </p>1289 <p id="rfc.section.4.3.7.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a <a href="#header.content-type" class="smpl">Content-Type</a> of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 7.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>) and contain a message body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable.1290 </p>1291 1256 <div id="rfc.iref.c.3"></div> 1292 <div id="rfc.iref.m. 8"></div>1293 <h3 id="rfc.section.4.3. 8"><a href="#rfc.section.4.3.8">4.3.8</a> <a id="CONNECT" href="#CONNECT">CONNECT</a></h3>1294 <p id="rfc.section.4.3. 8.p.1">The CONNECT method requests that the proxy establish a tunnel to the request-target and, if successful, thereafter restrict1257 <div id="rfc.iref.m.6"></div> 1258 <h3 id="rfc.section.4.3.6"><a href="#rfc.section.4.3.6">4.3.6</a> <a id="CONNECT" href="#CONNECT">CONNECT</a></h3> 1259 <p id="rfc.section.4.3.6.p.1">The CONNECT method requests that the proxy establish a tunnel to the request-target and, if successful, thereafter restrict 1295 1260 its behavior to blind forwarding of packets until the connection is closed. 1296 1261 </p> 1297 <p id="rfc.section.4.3. 8.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon.1262 <p id="rfc.section.4.3.6.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon. 1298 1263 For example, 1299 1264 </p> … … 1301 1266 Host: server.example.com:80 1302 1267 1303 </pre><p id="rfc.section.4.3. 8.p.4">Any <a href="#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request indicates that the proxy has established a connection to the requested host and port, and has1268 </pre><p id="rfc.section.4.3.6.p.4">Any <a href="#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request indicates that the proxy has established a connection to the requested host and port, and has 1304 1269 switched to tunneling the current connection to that server connection. The tunneled data from the server begins immediately 1305 1270 after the blank line that concludes the successful response's header block. 1306 1271 </p> 1307 <p id="rfc.section.4.3. 8.p.5">A server <em class="bcp14">SHOULD NOT</em> send any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> or <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> header fields in a successful response. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encoding header fields received in a successful response.1308 </p> 1309 <p id="rfc.section.4.3. 8.p.6">Any response other than a successful response indicates that the tunnel has not yet been formed and that the connection remains1272 <p id="rfc.section.4.3.6.p.5">A server <em class="bcp14">SHOULD NOT</em> send any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> or <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> header fields in a successful response. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encoding header fields received in a successful response. 1273 </p> 1274 <p id="rfc.section.4.3.6.p.6">Any response other than a successful response indicates that the tunnel has not yet been formed and that the connection remains 1310 1275 governed by HTTP. 1311 1276 </p> 1312 <p id="rfc.section.4.3. 8.p.7">Proxy authentication might be used to establish the authority to create a tunnel:</p>1277 <p id="rfc.section.4.3.6.p.7">Proxy authentication might be used to establish the authority to create a tunnel:</p> 1313 1278 <div id="rfc.figure.u.4"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1 1314 1279 Host: server.example.com:80 1315 1280 Proxy-Authorization: basic aGVsbG86d29ybGQ= 1316 1281 1317 </pre><p id="rfc.section.4.3. 8.p.9">A message body on a CONNECT request has no defined semantics. Sending a body on a CONNECT request might cause existing implementations1282 </pre><p id="rfc.section.4.3.6.p.9">A message body on a CONNECT request has no defined semantics. Sending a body on a CONNECT request might cause existing implementations 1318 1283 to reject the request. 1319 1284 </p> 1320 <p id="rfc.section.4.3. 8.p.10">Similar to a pipelined HTTP/1.1 request, data to be tunneled from client to server <em class="bcp14">MAY</em> be sent immediately after the request (before a response is received). The usual caveats also apply: data can be discarded1285 <p id="rfc.section.4.3.6.p.10">Similar to a pipelined HTTP/1.1 request, data to be tunneled from client to server <em class="bcp14">MAY</em> be sent immediately after the request (before a response is received). The usual caveats also apply: data can be discarded 1321 1286 if the eventual response is negative, and the connection can be reset with no response if more than one TCP segment is outstanding. 1322 1287 </p> 1323 <p id="rfc.section.4.3. 8.p.11">It might be the case that the proxy itself can only reach the requested origin server through another proxy. In this case,1288 <p id="rfc.section.4.3.6.p.11">It might be the case that the proxy itself can only reach the requested origin server through another proxy. In this case, 1324 1289 the first proxy <em class="bcp14">SHOULD</em> make a CONNECT request of that next proxy, requesting a tunnel to the authority. A proxy <em class="bcp14">MUST NOT</em> respond with any <a href="#status.2xx" class="smpl">2xx</a> status code unless it has either a direct or tunnel connection established to the authority. 1325 1290 </p> 1326 <p id="rfc.section.4.3. 8.p.12">If at any point either one of the peers gets disconnected, any outstanding data that came from that peer will be passed to1291 <p id="rfc.section.4.3.6.p.12">If at any point either one of the peers gets disconnected, any outstanding data that came from that peer will be passed to 1327 1292 the other one, and after that also the other connection will be terminated by the proxy. If there is outstanding data to that 1328 1293 peer undelivered, that data will be discarded. 1329 1294 </p> 1330 <p id="rfc.section.4.3.8.p.13">An origin server which receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a <a href="#status.2xx" class="smpl">2xx</a> status code to indicate that a connection is established. However, most origin servers do not implement CONNECT. 1295 <p id="rfc.section.4.3.6.p.13">An origin server which receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a <a href="#status.2xx" class="smpl">2xx</a> status code to indicate that a connection is established. However, most origin servers do not implement CONNECT. 1296 </p> 1297 <h3 id="rfc.section.4.3.7"><a href="#rfc.section.4.3.7">4.3.7</a> <a id="OPTIONS" href="#OPTIONS">OPTIONS</a></h3> 1298 <div id="rfc.iref.o.1"></div> 1299 <div id="rfc.iref.m.7"></div> 1300 <p id="rfc.section.4.3.7.p.1">The OPTIONS method requests information about the communication options available on the request/response chain identified 1301 by the effective request URI. This method allows a client to determine the options and/or requirements associated with a resource, 1302 or the capabilities of a server, without implying a resource action or initiating a resource retrieval. 1303 </p> 1304 <p id="rfc.section.4.3.7.p.2">Responses to the OPTIONS method are not cacheable.</p> 1305 <p id="rfc.section.4.3.7.p.3">If the OPTIONS request includes a message body (as indicated by the presence of <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> or <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a>), then the media type <em class="bcp14">MUST</em> be indicated by a <a href="#header.content-type" class="smpl">Content-Type</a> field. Although this specification does not define any use for such a body, future extensions to HTTP might use the OPTIONS 1306 body to make more detailed queries on the server. 1307 </p> 1308 <p id="rfc.section.4.3.7.p.4">If the request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>) is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource. 1309 Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" 1310 type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be 1311 used to test a proxy for HTTP/1.1 conformance (or lack thereof). 1312 </p> 1313 <p id="rfc.section.4.3.7.p.5">If the request-target is not an asterisk, the OPTIONS request applies only to the options that are available when communicating 1314 with that resource. 1315 </p> 1316 <p id="rfc.section.4.3.7.p.6">A <a href="#status.200" class="smpl">200 (OK)</a> response <em class="bcp14">SHOULD</em> include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., <a href="#header.allow" class="smpl">Allow</a>), possibly including extensions not defined by this specification. The response body, if any, <em class="bcp14">SHOULD</em> also include information about the communication options. The format for such a body is not defined by this specification, 1317 but might be defined by future extensions to HTTP. Content negotiation <em class="bcp14">MAY</em> be used to select the appropriate response format. If no response body is included, the response <em class="bcp14">MUST</em> include a <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> field with a field-value of "0". 1318 </p> 1319 <p id="rfc.section.4.3.7.p.7">The <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section 10.14</a>). If no Max-Forwards field is present in the request, then the forwarded request <em class="bcp14">MUST NOT</em> include a Max-Forwards field. 1320 </p> 1321 <h3 id="rfc.section.4.3.8"><a href="#rfc.section.4.3.8">4.3.8</a> <a id="TRACE" href="#TRACE">TRACE</a></h3> 1322 <div id="rfc.iref.t.1"></div> 1323 <div id="rfc.iref.m.8"></div> 1324 <p id="rfc.section.4.3.8.p.1">The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message body of a <a href="#status.200" class="smpl">200 (OK)</a> response. The final recipient is either the origin server or the first proxy to receive a <a href="#header.max-forwards" class="smpl">Max-Forwards</a> value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section 10.14</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body. 1325 </p> 1326 <p id="rfc.section.4.3.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 1327 or diagnostic information. The value of the <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field (<a href="p1-messaging.html#header.via" title="Via">Section 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding 1328 messages in an infinite loop. 1329 </p> 1330 <p id="rfc.section.4.3.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a <a href="#header.content-type" class="smpl">Content-Type</a> of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 7.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>) and contain a message body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable. 1331 1331 </p> 1332 1332 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="header.fields" href="#header.fields">Header Fields</a></h1> … … 2946 2946 <div id="rfc.iref.h.15"></div> 2947 2947 <h2 id="rfc.section.10.14"><a href="#rfc.section.10.14">10.14</a> <a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h2> 2948 <p id="rfc.section.10.14.p.1">The "Max-Forwards" header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section 4.3. 7</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section 4.3.1</a>) methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client is attempting2948 <p id="rfc.section.10.14.p.1">The "Max-Forwards" header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section 4.3.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section 4.3.7</a>) methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client is attempting 2949 2949 to trace a request which appears to be failing or looping mid-chain. 2950 2950 </p> … … 3080 3080 <td class="left">no</td> 3081 3081 <td class="left">no</td> 3082 <td class="left"> <a href="#CONNECT" id="rfc.xref.CONNECT.2" title="CONNECT">Section 4.3. 8</a>3082 <td class="left"> <a href="#CONNECT" id="rfc.xref.CONNECT.2" title="CONNECT">Section 4.3.6</a> 3083 3083 </td> 3084 3084 </tr> … … 3087 3087 <td class="left">no</td> 3088 3088 <td class="left">yes</td> 3089 <td class="left"> <a href="#DELETE" id="rfc.xref.DELETE.2" title="DELETE">Section 4.3. 6</a>3089 <td class="left"> <a href="#DELETE" id="rfc.xref.DELETE.2" title="DELETE">Section 4.3.5</a> 3090 3090 </td> 3091 3091 </tr> … … 3094 3094 <td class="left">yes</td> 3095 3095 <td class="left">yes</td> 3096 <td class="left"> <a href="#GET" id="rfc.xref.GET.2" title="GET">Section 4.3. 2</a>3096 <td class="left"> <a href="#GET" id="rfc.xref.GET.2" title="GET">Section 4.3.1</a> 3097 3097 </td> 3098 3098 </tr> … … 3101 3101 <td class="left">yes</td> 3102 3102 <td class="left">yes</td> 3103 <td class="left"> <a href="#HEAD" id="rfc.xref.HEAD.2" title="HEAD">Section 4.3. 3</a>3103 <td class="left"> <a href="#HEAD" id="rfc.xref.HEAD.2" title="HEAD">Section 4.3.2</a> 3104 3104 </td> 3105 3105 </tr> … … 3108 3108 <td class="left">yes</td> 3109 3109 <td class="left">yes</td> 3110 <td class="left"> <a href="#OPTIONS" id="rfc.xref.OPTIONS.3" title="OPTIONS">Section 4.3. 1</a>3110 <td class="left"> <a href="#OPTIONS" id="rfc.xref.OPTIONS.3" title="OPTIONS">Section 4.3.7</a> 3111 3111 </td> 3112 3112 </tr> … … 3115 3115 <td class="left">no</td> 3116 3116 <td class="left">no</td> 3117 <td class="left"> <a href="#POST" id="rfc.xref.POST.2" title="POST">Section 4.3. 4</a>3117 <td class="left"> <a href="#POST" id="rfc.xref.POST.2" title="POST">Section 4.3.3</a> 3118 3118 </td> 3119 3119 </tr> … … 3122 3122 <td class="left">no</td> 3123 3123 <td class="left">yes</td> 3124 <td class="left"> <a href="#PUT" id="rfc.xref.PUT.2" title="PUT">Section 4.3. 5</a>3124 <td class="left"> <a href="#PUT" id="rfc.xref.PUT.2" title="PUT">Section 4.3.4</a> 3125 3125 </td> 3126 3126 </tr> … … 3129 3129 <td class="left">yes</td> 3130 3130 <td class="left">yes</td> 3131 <td class="left"> <a href="#TRACE" id="rfc.xref.TRACE.3" title="TRACE">Section 4.3. 7</a>3131 <td class="left"> <a href="#TRACE" id="rfc.xref.TRACE.3" title="TRACE">Section 4.3.8</a> 3132 3132 </td> 3133 3133 </tr> … … 3700 3700 user. 3701 3701 </p> 3702 <p id="rfc.section.12.1.p.9">Some request methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section 4.3. 7</a>), expose information that was sent in request header fields within the body of their response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials, and other header fields that might be used3702 <p id="rfc.section.12.1.p.9">Some request methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section 4.3.8</a>), expose information that was sent in request header fields within the body of their response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials, and other header fields that might be used 3703 3703 to collect data from the client. 3704 3704 </p> … … 4022 4022 <p id="rfc.section.C.p.1">Introduce Method Registry. (<a href="#method.registry" title="Method Registry">Section 11.1</a>) 4023 4023 </p> 4024 <p id="rfc.section.C.p.2">Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST.3" title="POST">Section 4.3. 4</a>)4025 </p> 4026 <p id="rfc.section.C.p.3">Remove requirement to handle all Content-* header fields; ban use of <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> with PUT. (<a href="#PUT" id="rfc.xref.PUT.3" title="PUT">Section 4.3. 5</a>)4027 </p> 4028 <p id="rfc.section.C.p.4">Take over definition of CONNECT method from <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#CONNECT" id="rfc.xref.CONNECT.3" title="CONNECT">Section 4.3. 8</a>)4024 <p id="rfc.section.C.p.2">Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST.3" title="POST">Section 4.3.3</a>) 4025 </p> 4026 <p id="rfc.section.C.p.3">Remove requirement to handle all Content-* header fields; ban use of <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> with PUT. (<a href="#PUT" id="rfc.xref.PUT.3" title="PUT">Section 4.3.4</a>) 4027 </p> 4028 <p id="rfc.section.C.p.4">Take over definition of CONNECT method from <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#CONNECT" id="rfc.xref.CONNECT.3" title="CONNECT">Section 4.3.6</a>) 4029 4029 </p> 4030 4030 <p id="rfc.section.C.p.5">Take over the Status Code Registry, previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#status.code.registry" title="Status Code Registry">Section 11.2</a>) … … 4879 4879 </li> 4880 4880 <li>compress (Coding Format) <a href="#rfc.iref.c.4">7.4</a></li> 4881 <li>CONNECT method <a href="#rfc.xref.CONNECT.1">4.1</a>, <a href="#rfc.iref.c.3"><b>4.3. 8</b></a>, <a href="#rfc.xref.CONNECT.2">11.1.3</a>, <a href="#rfc.xref.CONNECT.3">C</a></li>4881 <li>CONNECT method <a href="#rfc.xref.CONNECT.1">4.1</a>, <a href="#rfc.iref.c.3"><b>4.3.6</b></a>, <a href="#rfc.xref.CONNECT.2">11.1.3</a>, <a href="#rfc.xref.CONNECT.3">C</a></li> 4882 4882 <li>content negotiation <a href="#rfc.iref.c.1">1</a></li> 4883 4883 <li>Content-Encoding header field <a href="#rfc.xref.header.content-encoding.1">3.2</a>, <a href="#rfc.xref.header.content-encoding.2">7.4</a>, <a href="#rfc.iref.c.8"><b>10.6</b></a>, <a href="#rfc.xref.header.content-encoding.3">11.3.2</a></li> 4884 4884 <li>Content-Language header field <a href="#rfc.xref.header.content-language.1">3.2</a>, <a href="#rfc.iref.c.9"><b>10.7</b></a>, <a href="#rfc.xref.header.content-language.2">11.3.2</a></li> 4885 <li>Content-Location header field <a href="#rfc.xref.header.content-location.1">3.2</a>, <a href="#rfc.xref.header.content-location.2">4.3. 4</a>, <a href="#rfc.iref.c.10"><b>10.8</b></a>, <a href="#rfc.xref.header.content-location.3">10.13</a>, <a href="#rfc.xref.header.content-location.4">11.3.2</a>, <a href="#rfc.xref.header.content-location.5">C</a></li>4885 <li>Content-Location header field <a href="#rfc.xref.header.content-location.1">3.2</a>, <a href="#rfc.xref.header.content-location.2">4.3.3</a>, <a href="#rfc.iref.c.10"><b>10.8</b></a>, <a href="#rfc.xref.header.content-location.3">10.13</a>, <a href="#rfc.xref.header.content-location.4">11.3.2</a>, <a href="#rfc.xref.header.content-location.5">C</a></li> 4886 4886 <li>Content-Transfer-Encoding header field <a href="#rfc.iref.c.12">A.5</a>, <a href="#rfc.xref.no.content-transfer-encoding.1">C</a></li> 4887 4887 <li>Content-Type header field <a href="#rfc.xref.header.content-type.1">3.2</a>, <a href="#rfc.xref.header.content-type.2">6</a>, <a href="#rfc.xref.header.content-type.3">7.5</a>, <a href="#rfc.iref.c.11"><b>10.9</b></a>, <a href="#rfc.xref.header.content-type.4">11.3.1</a>, <a href="#rfc.xref.header.content-type.5">11.3.2</a></li> … … 4891 4891 <li>Date header field <a href="#rfc.xref.header.date.1">5.6</a>, <a href="#rfc.iref.d.3"><b>10.10</b></a>, <a href="#rfc.xref.header.date.2">11.3.2</a></li> 4892 4892 <li>deflate (Coding Format) <a href="#rfc.iref.d.2">7.4</a></li> 4893 <li>DELETE method <a href="#rfc.xref.DELETE.1">4.1</a>, <a href="#rfc.iref.d.1"><b>4.3. 6</b></a>, <a href="#rfc.xref.DELETE.2">11.1.3</a></li>4893 <li>DELETE method <a href="#rfc.xref.DELETE.1">4.1</a>, <a href="#rfc.iref.d.1"><b>4.3.5</b></a>, <a href="#rfc.xref.DELETE.2">11.1.3</a></li> 4894 4894 </ul> 4895 4895 </li> … … 4908 4908 </li> 4909 4909 <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul> 4910 <li>GET method <a href="#rfc.xref.GET.1">4.1</a>, <a href="#rfc.iref.g.2"><b>4.3. 2</b></a>, <a href="#rfc.xref.GET.2">11.1.3</a></li>4910 <li>GET method <a href="#rfc.xref.GET.1">4.1</a>, <a href="#rfc.iref.g.2"><b>4.3.1</b></a>, <a href="#rfc.xref.GET.2">11.1.3</a></li> 4911 4911 <li><tt>Grammar</tt> 4912 4912 <ul> … … 4976 4976 </li> 4977 4977 <li><a id="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul> 4978 <li>HEAD method <a href="#rfc.xref.HEAD.1">4.1</a>, <a href="#rfc.iref.h.1"><b>4.3. 3</b></a>, <a href="#rfc.xref.HEAD.2">11.1.3</a></li>4978 <li>HEAD method <a href="#rfc.xref.HEAD.1">4.1</a>, <a href="#rfc.iref.h.1"><b>4.3.2</b></a>, <a href="#rfc.xref.HEAD.2">11.1.3</a></li> 4979 4979 <li>Header Fields 4980 4980 <ul> … … 4986 4986 <li>Content-Encoding <a href="#rfc.xref.header.content-encoding.1">3.2</a>, <a href="#rfc.xref.header.content-encoding.2">7.4</a>, <a href="#rfc.iref.h.7"><b>10.6</b></a>, <a href="#rfc.xref.header.content-encoding.3">11.3.2</a></li> 4987 4987 <li>Content-Language <a href="#rfc.xref.header.content-language.1">3.2</a>, <a href="#rfc.iref.h.8"><b>10.7</b></a>, <a href="#rfc.xref.header.content-language.2">11.3.2</a></li> 4988 <li>Content-Location <a href="#rfc.xref.header.content-location.1">3.2</a>, <a href="#rfc.xref.header.content-location.2">4.3. 4</a>, <a href="#rfc.iref.h.9"><b>10.8</b></a>, <a href="#rfc.xref.header.content-location.3">10.13</a>, <a href="#rfc.xref.header.content-location.4">11.3.2</a>, <a href="#rfc.xref.header.content-location.5">C</a></li>4988 <li>Content-Location <a href="#rfc.xref.header.content-location.1">3.2</a>, <a href="#rfc.xref.header.content-location.2">4.3.3</a>, <a href="#rfc.iref.h.9"><b>10.8</b></a>, <a href="#rfc.xref.header.content-location.3">10.13</a>, <a href="#rfc.xref.header.content-location.4">11.3.2</a>, <a href="#rfc.xref.header.content-location.5">C</a></li> 4989 4989 <li>Content-Transfer-Encoding <a href="#rfc.iref.h.21">A.5</a>, <a href="#rfc.xref.no.content-transfer-encoding.1">C</a></li> 4990 4990 <li>Content-Type <a href="#rfc.xref.header.content-type.1">3.2</a>, <a href="#rfc.xref.header.content-type.2">6</a>, <a href="#rfc.xref.header.content-type.3">7.5</a>, <a href="#rfc.iref.h.10"><b>10.9</b></a>, <a href="#rfc.xref.header.content-type.4">11.3.1</a>, <a href="#rfc.xref.header.content-type.5">11.3.2</a></li> … … 4992 4992 <li>Expect <a href="#rfc.xref.header.expect.1">5.5</a>, <a href="#rfc.xref.header.expect.2">6.5.14</a>, <a href="#rfc.iref.h.12"><b>10.11</b></a>, <a href="#rfc.xref.header.expect.3">11.3.2</a>, <a href="#rfc.xref.header.expect.4">C</a></li> 4993 4993 <li>From <a href="#rfc.xref.header.from.1">5.5</a>, <a href="#rfc.iref.h.13"><b>10.12</b></a>, <a href="#rfc.xref.header.from.2">11.3.2</a></li> 4994 <li>Location <a href="#rfc.xref.header.location.1">4.3. 4</a>, <a href="#rfc.xref.header.location.2">5.6</a>, <a href="#rfc.xref.header.location.3">6.4</a>, <a href="#rfc.iref.h.14"><b>10.13</b></a>, <a href="#rfc.xref.header.location.4">11.3.2</a>, <a href="#rfc.xref.header.location.5">C</a></li>4995 <li>Max-Forwards <a href="#rfc.xref.header.max-forwards.1">4.3. 1</a>, <a href="#rfc.xref.header.max-forwards.2">4.3.7</a>, <a href="#rfc.xref.header.max-forwards.3">5.5</a>, <a href="#rfc.iref.h.15"><b>10.14</b></a>, <a href="#rfc.xref.header.max-forwards.4">11.3.2</a>, <a href="#rfc.xref.header.max-forwards.5">C</a></li>4994 <li>Location <a href="#rfc.xref.header.location.1">4.3.3</a>, <a href="#rfc.xref.header.location.2">5.6</a>, <a href="#rfc.xref.header.location.3">6.4</a>, <a href="#rfc.iref.h.14"><b>10.13</b></a>, <a href="#rfc.xref.header.location.4">11.3.2</a>, <a href="#rfc.xref.header.location.5">C</a></li> 4995 <li>Max-Forwards <a href="#rfc.xref.header.max-forwards.1">4.3.7</a>, <a href="#rfc.xref.header.max-forwards.2">4.3.8</a>, <a href="#rfc.xref.header.max-forwards.3">5.5</a>, <a href="#rfc.iref.h.15"><b>10.14</b></a>, <a href="#rfc.xref.header.max-forwards.4">11.3.2</a>, <a href="#rfc.xref.header.max-forwards.5">C</a></li> 4996 4996 <li>MIME-Version <a href="#rfc.xref.mime-version.1">11.3.2</a>, <a href="#rfc.iref.h.20"><b>A.1</b></a></li> 4997 4997 <li>Referer <a href="#rfc.xref.header.referer.1">5.5</a>, <a href="#rfc.iref.h.16"><b>10.15</b></a>, <a href="#rfc.xref.header.referer.2">11.3.2</a>, <a href="#rfc.xref.header.referer.3">C</a></li> … … 5008 5008 </li> 5009 5009 <li><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul> 5010 <li>Location header field <a href="#rfc.xref.header.location.1">4.3. 4</a>, <a href="#rfc.xref.header.location.2">5.6</a>, <a href="#rfc.xref.header.location.3">6.4</a>, <a href="#rfc.iref.l.1"><b>10.13</b></a>, <a href="#rfc.xref.header.location.4">11.3.2</a>, <a href="#rfc.xref.header.location.5">C</a></li>5010 <li>Location header field <a href="#rfc.xref.header.location.1">4.3.3</a>, <a href="#rfc.xref.header.location.2">5.6</a>, <a href="#rfc.xref.header.location.3">6.4</a>, <a href="#rfc.iref.l.1"><b>10.13</b></a>, <a href="#rfc.xref.header.location.4">11.3.2</a>, <a href="#rfc.xref.header.location.5">C</a></li> 5011 5011 </ul> 5012 5012 </li> 5013 5013 <li><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul> 5014 <li>Max-Forwards header field <a href="#rfc.xref.header.max-forwards.1">4.3. 1</a>, <a href="#rfc.xref.header.max-forwards.2">4.3.7</a>, <a href="#rfc.xref.header.max-forwards.3">5.5</a>, <a href="#rfc.iref.m.9"><b>10.14</b></a>, <a href="#rfc.xref.header.max-forwards.4">11.3.2</a>, <a href="#rfc.xref.header.max-forwards.5">C</a></li>5014 <li>Max-Forwards header field <a href="#rfc.xref.header.max-forwards.1">4.3.7</a>, <a href="#rfc.xref.header.max-forwards.2">4.3.8</a>, <a href="#rfc.xref.header.max-forwards.3">5.5</a>, <a href="#rfc.iref.m.9"><b>10.14</b></a>, <a href="#rfc.xref.header.max-forwards.4">11.3.2</a>, <a href="#rfc.xref.header.max-forwards.5">C</a></li> 5015 5015 <li>Methods 5016 5016 <ul> 5017 <li>CONNECT <a href="#rfc.xref.CONNECT.1">4.1</a>, <a href="#rfc.iref.m. 8"><b>4.3.8</b></a>, <a href="#rfc.xref.CONNECT.2">11.1.3</a>, <a href="#rfc.xref.CONNECT.3">C</a></li>5018 <li>DELETE <a href="#rfc.xref.DELETE.1">4.1</a>, <a href="#rfc.iref.m. 6"><b>4.3.6</b></a>, <a href="#rfc.xref.DELETE.2">11.1.3</a></li>5019 <li>GET <a href="#rfc.xref.GET.1">4.1</a>, <a href="#rfc.iref.m. 2"><b>4.3.2</b></a>, <a href="#rfc.xref.GET.2">11.1.3</a></li>5020 <li>HEAD <a href="#rfc.xref.HEAD.1">4.1</a>, <a href="#rfc.iref.m. 3"><b>4.3.3</b></a>, <a href="#rfc.xref.HEAD.2">11.1.3</a></li>5021 <li>OPTIONS <a href="#rfc.xref.OPTIONS.1">4.1</a>, <a href="#rfc.iref.m. 1"><b>4.3.1</b></a>, <a href="#rfc.xref.OPTIONS.2">10.14</a>, <a href="#rfc.xref.OPTIONS.3">11.1.3</a></li>5022 <li>POST <a href="#rfc.xref.POST.1">4.1</a>, <a href="#rfc.iref.m. 4"><b>4.3.4</b></a>, <a href="#rfc.xref.POST.2">11.1.3</a>, <a href="#rfc.xref.POST.3">C</a></li>5023 <li>PUT <a href="#rfc.xref.PUT.1">4.1</a>, <a href="#rfc.iref.m. 5"><b>4.3.5</b></a>, <a href="#rfc.xref.PUT.2">11.1.3</a>, <a href="#rfc.xref.PUT.3">C</a></li>5024 <li>TRACE <a href="#rfc.xref.TRACE.1">4.1</a>, <a href="#rfc.iref.m. 7"><b>4.3.7</b></a>, <a href="#rfc.xref.TRACE.2">10.14</a>, <a href="#rfc.xref.TRACE.3">11.1.3</a>, <a href="#rfc.xref.TRACE.4">12.1</a></li>5017 <li>CONNECT <a href="#rfc.xref.CONNECT.1">4.1</a>, <a href="#rfc.iref.m.6"><b>4.3.6</b></a>, <a href="#rfc.xref.CONNECT.2">11.1.3</a>, <a href="#rfc.xref.CONNECT.3">C</a></li> 5018 <li>DELETE <a href="#rfc.xref.DELETE.1">4.1</a>, <a href="#rfc.iref.m.5"><b>4.3.5</b></a>, <a href="#rfc.xref.DELETE.2">11.1.3</a></li> 5019 <li>GET <a href="#rfc.xref.GET.1">4.1</a>, <a href="#rfc.iref.m.1"><b>4.3.1</b></a>, <a href="#rfc.xref.GET.2">11.1.3</a></li> 5020 <li>HEAD <a href="#rfc.xref.HEAD.1">4.1</a>, <a href="#rfc.iref.m.2"><b>4.3.2</b></a>, <a href="#rfc.xref.HEAD.2">11.1.3</a></li> 5021 <li>OPTIONS <a href="#rfc.xref.OPTIONS.1">4.1</a>, <a href="#rfc.iref.m.7"><b>4.3.7</b></a>, <a href="#rfc.xref.OPTIONS.2">10.14</a>, <a href="#rfc.xref.OPTIONS.3">11.1.3</a></li> 5022 <li>POST <a href="#rfc.xref.POST.1">4.1</a>, <a href="#rfc.iref.m.3"><b>4.3.3</b></a>, <a href="#rfc.xref.POST.2">11.1.3</a>, <a href="#rfc.xref.POST.3">C</a></li> 5023 <li>PUT <a href="#rfc.xref.PUT.1">4.1</a>, <a href="#rfc.iref.m.4"><b>4.3.4</b></a>, <a href="#rfc.xref.PUT.2">11.1.3</a>, <a href="#rfc.xref.PUT.3">C</a></li> 5024 <li>TRACE <a href="#rfc.xref.TRACE.1">4.1</a>, <a href="#rfc.iref.m.8"><b>4.3.8</b></a>, <a href="#rfc.xref.TRACE.2">10.14</a>, <a href="#rfc.xref.TRACE.3">11.1.3</a>, <a href="#rfc.xref.TRACE.4">12.1</a></li> 5025 5025 </ul> 5026 5026 </li> … … 5029 5029 </li> 5030 5030 <li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul> 5031 <li>OPTIONS method <a href="#rfc.xref.OPTIONS.1">4.1</a>, <a href="#rfc.iref.o.1"><b>4.3. 1</b></a>, <a href="#rfc.xref.OPTIONS.2">10.14</a>, <a href="#rfc.xref.OPTIONS.3">11.1.3</a></li>5031 <li>OPTIONS method <a href="#rfc.xref.OPTIONS.1">4.1</a>, <a href="#rfc.iref.o.1"><b>4.3.7</b></a>, <a href="#rfc.xref.OPTIONS.2">10.14</a>, <a href="#rfc.xref.OPTIONS.3">11.1.3</a></li> 5032 5032 </ul> 5033 5033 </li> 5034 5034 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 5035 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3</a>, <a href="#rfc.xref.Part1.8">3.1</a>, <a href="#rfc.xref.Part1.9">4.3. 1</a>, <a href="#rfc.xref.Part1.10">4.3.7</a>, <a href="#rfc.xref.Part1.11">4.3.7</a>, <a href="#rfc.xref.Part1.12">4.3.8</a>, <a href="#rfc.xref.Part1.13">5.5</a>, <a href="#rfc.xref.Part1.14">5.5</a>, <a href="#rfc.xref.Part1.15">5.6</a>, <a href="#rfc.xref.Part1.16">6.2.1</a>, <a href="#rfc.xref.Part1.17">6.2.2</a>, <a href="#rfc.xref.Part1.18">6.3.4</a>, <a href="#rfc.xref.Part1.19">6.3.6</a>, <a href="#rfc.xref.Part1.20">6.5.15</a>, <a href="#rfc.xref.Part1.21">6.6.6</a>, <a href="#rfc.xref.Part1.22">7.4</a>, <a href="#rfc.xref.Part1.23">7.4</a>, <a href="#rfc.xref.Part1.24">7.4</a>, <a href="#rfc.xref.Part1.25">8.1</a>, <a href="#rfc.xref.Part1.26">8.2</a>, <a href="#rfc.xref.Part1.27">10.8</a>, <a href="#rfc.xref.Part1.28">10.11</a>, <a href="#rfc.xref.Part1.29">10.17</a>, <a href="#rfc.xref.Part1.30">10.17</a>, <a href="#rfc.xref.Part1.31">10.18</a>, <a href="#rfc.xref.Part1.32">11.1.2</a>, <a href="#rfc.xref.Part1.33">11.3.1</a>, <a href="#rfc.xref.Part1.34">11.3.1</a>, <a href="#rfc.xref.Part1.35">11.3.1</a>, <a href="#rfc.xref.Part1.36">11.3.1</a>, <a href="#rfc.xref.Part1.37">11.3.1</a>, <a href="#rfc.xref.Part1.38">11.3.1</a>, <a href="#rfc.xref.Part1.39">11.4</a>, <a href="#rfc.xref.Part1.40">11.4.1</a>, <a href="#rfc.xref.Part1.41">11.4.1</a>, <a href="#rfc.xref.Part1.42">11.4.2</a>, <a href="#rfc.xref.Part1.43">11.4.2</a>, <a href="#rfc.xref.Part1.44">11.4.2</a>, <a href="#rfc.xref.Part1.45">13</a>, <a href="#Part1"><b>14.1</b></a>, <a href="#rfc.xref.Part1.46">C</a>, <a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a>, <a href="#rfc.xref.Part1.49">D</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.52">D</a>, <a href="#rfc.xref.Part1.53">D</a>, <a href="#rfc.xref.Part1.54">D</a>, <a href="#rfc.xref.Part1.55">D</a>, <a href="#rfc.xref.Part1.56">D</a>, <a href="#rfc.xref.Part1.57">D</a><ul>5035 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3</a>, <a href="#rfc.xref.Part1.8">3.1</a>, <a href="#rfc.xref.Part1.9">4.3.6</a>, <a href="#rfc.xref.Part1.10">4.3.7</a>, <a href="#rfc.xref.Part1.11">4.3.8</a>, <a href="#rfc.xref.Part1.12">4.3.8</a>, <a href="#rfc.xref.Part1.13">5.5</a>, <a href="#rfc.xref.Part1.14">5.5</a>, <a href="#rfc.xref.Part1.15">5.6</a>, <a href="#rfc.xref.Part1.16">6.2.1</a>, <a href="#rfc.xref.Part1.17">6.2.2</a>, <a href="#rfc.xref.Part1.18">6.3.4</a>, <a href="#rfc.xref.Part1.19">6.3.6</a>, <a href="#rfc.xref.Part1.20">6.5.15</a>, <a href="#rfc.xref.Part1.21">6.6.6</a>, <a href="#rfc.xref.Part1.22">7.4</a>, <a href="#rfc.xref.Part1.23">7.4</a>, <a href="#rfc.xref.Part1.24">7.4</a>, <a href="#rfc.xref.Part1.25">8.1</a>, <a href="#rfc.xref.Part1.26">8.2</a>, <a href="#rfc.xref.Part1.27">10.8</a>, <a href="#rfc.xref.Part1.28">10.11</a>, <a href="#rfc.xref.Part1.29">10.17</a>, <a href="#rfc.xref.Part1.30">10.17</a>, <a href="#rfc.xref.Part1.31">10.18</a>, <a href="#rfc.xref.Part1.32">11.1.2</a>, <a href="#rfc.xref.Part1.33">11.3.1</a>, <a href="#rfc.xref.Part1.34">11.3.1</a>, <a href="#rfc.xref.Part1.35">11.3.1</a>, <a href="#rfc.xref.Part1.36">11.3.1</a>, <a href="#rfc.xref.Part1.37">11.3.1</a>, <a href="#rfc.xref.Part1.38">11.3.1</a>, <a href="#rfc.xref.Part1.39">11.4</a>, <a href="#rfc.xref.Part1.40">11.4.1</a>, <a href="#rfc.xref.Part1.41">11.4.1</a>, <a href="#rfc.xref.Part1.42">11.4.2</a>, <a href="#rfc.xref.Part1.43">11.4.2</a>, <a href="#rfc.xref.Part1.44">11.4.2</a>, <a href="#rfc.xref.Part1.45">13</a>, <a href="#Part1"><b>14.1</b></a>, <a href="#rfc.xref.Part1.46">C</a>, <a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a>, <a href="#rfc.xref.Part1.49">D</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.52">D</a>, <a href="#rfc.xref.Part1.53">D</a>, <a href="#rfc.xref.Part1.54">D</a>, <a href="#rfc.xref.Part1.55">D</a>, <a href="#rfc.xref.Part1.56">D</a>, <a href="#rfc.xref.Part1.57">D</a><ul> 5036 5036 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.3">1.2</a></li> 5037 5037 <li><em>Section 2.3</em> <a href="#rfc.xref.Part1.18">6.3.4</a></li> … … 5051 5051 <li><em>Section 4.2.3</em> <a href="#rfc.xref.Part1.24">7.4</a>, <a href="#rfc.xref.Part1.44">11.4.2</a></li> 5052 5052 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.14">5.5</a></li> 5053 <li><em>Section 5.3</em> <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.9">4.3. 1</a>, <a href="#rfc.xref.Part1.12">4.3.8</a></li>5053 <li><em>Section 5.3</em> <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.9">4.3.6</a>, <a href="#rfc.xref.Part1.10">4.3.7</a></li> 5054 5054 <li><em>Section 5.4</em> <a href="#rfc.xref.Part1.13">5.5</a></li> 5055 5055 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.8">3.1</a>, <a href="#rfc.xref.Part1.15">5.6</a>, <a href="#rfc.xref.Part1.27">10.8</a></li> 5056 <li><em>Section 5.7</em> <a href="#rfc.xref.Part1.1 0">4.3.7</a>, <a href="#rfc.xref.Part1.30">10.17</a>, <a href="#rfc.xref.Part1.46">C</a></li>5056 <li><em>Section 5.7</em> <a href="#rfc.xref.Part1.11">4.3.8</a>, <a href="#rfc.xref.Part1.30">10.17</a>, <a href="#rfc.xref.Part1.46">C</a></li> 5057 5057 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.37">11.3.1</a></li> 5058 5058 <li><em>Section 6.3</em> <a href="#rfc.xref.Part1.16">6.2.1</a>, <a href="#rfc.xref.Part1.28">10.11</a></li> 5059 5059 <li><em>Section 6.4</em> <a href="#rfc.xref.Part1.17">6.2.2</a>, <a href="#rfc.xref.Part1.20">6.5.15</a></li> 5060 <li><em>Section 7.3.1</em> <a href="#rfc.xref.Part1.1 1">4.3.7</a></li>5060 <li><em>Section 7.3.1</em> <a href="#rfc.xref.Part1.12">4.3.8</a></li> 5061 5061 <li><em>Section 9</em> <a href="#rfc.xref.Part1.45">13</a></li> 5062 5062 <li><em>Appendix B</em> <a href="#rfc.xref.Part1.34">11.3.1</a></li> 5063 5063 </ul> 5064 5064 </li> 5065 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">3.2</a>, <a href="#rfc.xref.Part4.2">3.2</a>, <a href="#rfc.xref.Part4.3">4.3. 2</a>, <a href="#rfc.xref.Part4.4">5.5</a>, <a href="#rfc.xref.Part4.5">5.5</a>, <a href="#rfc.xref.Part4.6">5.5</a>, <a href="#rfc.xref.Part4.7">5.5</a>, <a href="#rfc.xref.Part4.8">5.6</a>, <a href="#rfc.xref.Part4.9">6.1</a>, <a href="#rfc.xref.Part4.10">6.1</a>, <a href="#rfc.xref.Part4.11">6.1</a>, <a href="#rfc.xref.Part4.12">6.3.2</a>, <a href="#rfc.xref.Part4.13">6.4</a>, <a href="#Part4"><b>14.1</b></a>, <a href="#rfc.xref.Part4.14">F.2</a><ul>5065 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">3.2</a>, <a href="#rfc.xref.Part4.2">3.2</a>, <a href="#rfc.xref.Part4.3">4.3.1</a>, <a href="#rfc.xref.Part4.4">5.5</a>, <a href="#rfc.xref.Part4.5">5.5</a>, <a href="#rfc.xref.Part4.6">5.5</a>, <a href="#rfc.xref.Part4.7">5.5</a>, <a href="#rfc.xref.Part4.8">5.6</a>, <a href="#rfc.xref.Part4.9">6.1</a>, <a href="#rfc.xref.Part4.10">6.1</a>, <a href="#rfc.xref.Part4.11">6.1</a>, <a href="#rfc.xref.Part4.12">6.3.2</a>, <a href="#rfc.xref.Part4.13">6.4</a>, <a href="#Part4"><b>14.1</b></a>, <a href="#rfc.xref.Part4.14">F.2</a><ul> 5066 5066 <li><em>Section 2.2</em> <a href="#rfc.xref.Part4.2">3.2</a></li> 5067 5067 <li><em>Section 2.3</em> <a href="#rfc.xref.Part4.1">3.2</a>, <a href="#rfc.xref.Part4.8">5.6</a>, <a href="#rfc.xref.Part4.12">6.3.2</a></li> … … 5075 5075 </ul> 5076 5076 </li> 5077 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">4.3. 2</a>, <a href="#rfc.xref.Part5.2">4.3.2</a>, <a href="#rfc.xref.Part5.3">4.3.5</a>, <a href="#rfc.xref.Part5.4">5.5</a>, <a href="#rfc.xref.Part5.5">5.5</a>, <a href="#rfc.xref.Part5.6">5.6</a>, <a href="#rfc.xref.Part5.7">6.1</a>, <a href="#rfc.xref.Part5.8">6.1</a>, <a href="#rfc.xref.Part5.9">6.1</a>, <a href="#rfc.xref.Part5.10">8.1</a>, <a href="#Part5"><b>14.1</b></a><ul>5077 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">4.3.1</a>, <a href="#rfc.xref.Part5.2">4.3.1</a>, <a href="#rfc.xref.Part5.3">4.3.4</a>, <a href="#rfc.xref.Part5.4">5.5</a>, <a href="#rfc.xref.Part5.5">5.5</a>, <a href="#rfc.xref.Part5.6">5.6</a>, <a href="#rfc.xref.Part5.7">6.1</a>, <a href="#rfc.xref.Part5.8">6.1</a>, <a href="#rfc.xref.Part5.9">6.1</a>, <a href="#rfc.xref.Part5.10">8.1</a>, <a href="#Part5"><b>14.1</b></a><ul> 5078 5078 <li><em>Section 3</em> <a href="#rfc.xref.Part5.7">6.1</a></li> 5079 5079 <li><em>Section 3.1</em> <a href="#rfc.xref.Part5.8">6.1</a></li> 5080 5080 <li><em>Section 3.2</em> <a href="#rfc.xref.Part5.9">6.1</a></li> 5081 5081 <li><em>Section 5.1</em> <a href="#rfc.xref.Part5.6">5.6</a></li> 5082 <li><em>Section 5.2</em> <a href="#rfc.xref.Part5.3">4.3. 5</a>, <a href="#rfc.xref.Part5.10">8.1</a></li>5082 <li><em>Section 5.2</em> <a href="#rfc.xref.Part5.3">4.3.4</a>, <a href="#rfc.xref.Part5.10">8.1</a></li> 5083 5083 <li><em>Section 5.3</em> <a href="#rfc.xref.Part5.4">5.5</a></li> 5084 <li><em>Section 5.4</em> <a href="#rfc.xref.Part5.2">4.3. 2</a>, <a href="#rfc.xref.Part5.5">5.5</a></li>5084 <li><em>Section 5.4</em> <a href="#rfc.xref.Part5.2">4.3.1</a>, <a href="#rfc.xref.Part5.5">5.5</a></li> 5085 5085 </ul> 5086 5086 </li> 5087 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">3.2</a>, <a href="#rfc.xref.Part6.2">4.2.3</a>, <a href="#rfc.xref.Part6.3">4.3. 2</a>, <a href="#rfc.xref.Part6.4">4.3.3</a>, <a href="#rfc.xref.Part6.5">4.3.4</a>, <a href="#rfc.xref.Part6.6">4.3.5</a>, <a href="#rfc.xref.Part6.7">4.3.6</a>, <a href="#rfc.xref.Part6.8">5.6</a>, <a href="#rfc.xref.Part6.9">5.6</a>, <a href="#rfc.xref.Part6.10">6.3.1</a>, <a href="#rfc.xref.Part6.11">6.3.4</a>, <a href="#rfc.xref.Part6.12">6.3.4</a>, <a href="#rfc.xref.Part6.13">6.3.4</a>, <a href="#rfc.xref.Part6.14">6.4.1</a>, <a href="#rfc.xref.Part6.15">6.4.2</a>, <a href="#rfc.xref.Part6.16">6.5.9</a>, <a href="#rfc.xref.Part6.17">9.1</a>, <a href="#rfc.xref.Part6.18">11.2.2</a>, <a href="#rfc.xref.Part6.19">11.3.1</a>, <a href="#Part6"><b>14.1</b></a><ul>5088 <li><em>Section 4.1.1</em> <a href="#rfc.xref.Part6.5">4.3. 4</a></li>5087 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">3.2</a>, <a href="#rfc.xref.Part6.2">4.2.3</a>, <a href="#rfc.xref.Part6.3">4.3.1</a>, <a href="#rfc.xref.Part6.4">4.3.2</a>, <a href="#rfc.xref.Part6.5">4.3.3</a>, <a href="#rfc.xref.Part6.6">4.3.4</a>, <a href="#rfc.xref.Part6.7">4.3.5</a>, <a href="#rfc.xref.Part6.8">5.6</a>, <a href="#rfc.xref.Part6.9">5.6</a>, <a href="#rfc.xref.Part6.10">6.3.1</a>, <a href="#rfc.xref.Part6.11">6.3.4</a>, <a href="#rfc.xref.Part6.12">6.3.4</a>, <a href="#rfc.xref.Part6.13">6.3.4</a>, <a href="#rfc.xref.Part6.14">6.4.1</a>, <a href="#rfc.xref.Part6.15">6.4.2</a>, <a href="#rfc.xref.Part6.16">6.5.9</a>, <a href="#rfc.xref.Part6.17">9.1</a>, <a href="#rfc.xref.Part6.18">11.2.2</a>, <a href="#rfc.xref.Part6.19">11.3.1</a>, <a href="#Part6"><b>14.1</b></a><ul> 5088 <li><em>Section 4.1.1</em> <a href="#rfc.xref.Part6.5">4.3.3</a></li> 5089 5089 <li><em>Section 4.1.2</em> <a href="#rfc.xref.Part6.10">6.3.1</a>, <a href="#rfc.xref.Part6.13">6.3.4</a>, <a href="#rfc.xref.Part6.14">6.4.1</a>, <a href="#rfc.xref.Part6.15">6.4.2</a>, <a href="#rfc.xref.Part6.16">6.5.9</a></li> 5090 <li><em>Section 5</em> <a href="#rfc.xref.Part6.4">4.3. 3</a></li>5091 <li><em>Section 6</em> <a href="#rfc.xref.Part6.6">4.3. 5</a>, <a href="#rfc.xref.Part6.7">4.3.6</a></li>5090 <li><em>Section 5</em> <a href="#rfc.xref.Part6.4">4.3.2</a></li> 5091 <li><em>Section 6</em> <a href="#rfc.xref.Part6.6">4.3.4</a>, <a href="#rfc.xref.Part6.7">4.3.5</a></li> 5092 5092 <li><em>Section 7.1</em> <a href="#rfc.xref.Part6.8">5.6</a></li> 5093 5093 <li><em>Section 7.2</em> <a href="#rfc.xref.Part6.11">6.3.4</a></li> … … 5108 5108 </li> 5109 5109 <li>payload <a href="#rfc.iref.p.3">8</a></li> 5110 <li>POST method <a href="#rfc.xref.POST.1">4.1</a>, <a href="#rfc.iref.p.1"><b>4.3. 4</b></a>, <a href="#rfc.xref.POST.2">11.1.3</a>, <a href="#rfc.xref.POST.3">C</a></li>5111 <li>PUT method <a href="#rfc.xref.PUT.1">4.1</a>, <a href="#rfc.iref.p.2"><b>4.3. 5</b></a>, <a href="#rfc.xref.PUT.2">11.1.3</a>, <a href="#rfc.xref.PUT.3">C</a></li>5110 <li>POST method <a href="#rfc.xref.POST.1">4.1</a>, <a href="#rfc.iref.p.1"><b>4.3.3</b></a>, <a href="#rfc.xref.POST.2">11.1.3</a>, <a href="#rfc.xref.POST.3">C</a></li> 5111 <li>PUT method <a href="#rfc.xref.PUT.1">4.1</a>, <a href="#rfc.iref.p.2"><b>4.3.4</b></a>, <a href="#rfc.xref.PUT.2">11.1.3</a>, <a href="#rfc.xref.PUT.3">C</a></li> 5112 5112 </ul> 5113 5113 </li> … … 5197 5197 </ul> 5198 5198 </li> 5199 <li><em>RFC5789</em> <a href="#rfc.xref.RFC5789.1">4.3. 5</a>, <a href="#RFC5789"><b>14.2</b></a></li>5199 <li><em>RFC5789</em> <a href="#rfc.xref.RFC5789.1">4.3.4</a>, <a href="#RFC5789"><b>14.2</b></a></li> 5200 5200 <li><em>RFC5987</em> <a href="#rfc.xref.RFC5987.1">11.3.1</a>, <a href="#RFC5987"><b>14.2</b></a></li> 5201 5201 <li><em>RFC6151</em> <a href="#RFC6151"><b>14.2</b></a>, <a href="#rfc.xref.RFC6151.1">C</a></li> … … 5260 5260 </li> 5261 5261 <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul> 5262 <li>TRACE method <a href="#rfc.xref.TRACE.1">4.1</a>, <a href="#rfc.iref.t.1"><b>4.3. 7</b></a>, <a href="#rfc.xref.TRACE.2">10.14</a>, <a href="#rfc.xref.TRACE.3">11.1.3</a>, <a href="#rfc.xref.TRACE.4">12.1</a></li>5262 <li>TRACE method <a href="#rfc.xref.TRACE.1">4.1</a>, <a href="#rfc.iref.t.1"><b>4.3.8</b></a>, <a href="#rfc.xref.TRACE.2">10.14</a>, <a href="#rfc.xref.TRACE.3">11.1.3</a>, <a href="#rfc.xref.TRACE.4">12.1</a></li> 5263 5263 </ul> 5264 5264 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1849 r1850 653 653 <section title="Method Definitions" anchor="method.definitions"> 654 654 655 <section title="OPTIONS" anchor="OPTIONS">656 <rdf:Description>657 <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe>658 <idempotent xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</idempotent>659 </rdf:Description>660 <iref primary="true" item="OPTIONS method" x:for-anchor=""/>661 <iref primary="true" item="Methods" subitem="OPTIONS" x:for-anchor=""/>662 <t>663 The OPTIONS method requests information about the664 communication options available on the request/response chain665 identified by the effective request URI. This method allows a client to666 determine the options and/or requirements associated with a resource,667 or the capabilities of a server, without implying a resource action668 or initiating a resource retrieval.669 </t>670 <t>671 Responses to the OPTIONS method are not cacheable.672 </t>673 <t>674 If the OPTIONS request includes a message body (as indicated by the675 presence of <x:ref>Content-Length</x:ref> or <x:ref>Transfer-Encoding</x:ref>),676 then the media type &MUST; be indicated by a <x:ref>Content-Type</x:ref>677 field. Although this specification does not define any use for such a body,678 future extensions to HTTP might use the OPTIONS body to make more detailed679 queries on the server.680 </t>681 <t>682 If the request-target (&request-target;) is an asterisk ("*"),683 the OPTIONS request is684 intended to apply to the server in general rather than to a specific685 resource. Since a server's communication options typically depend on686 the resource, the "*" request is only useful as a "ping" or "no-op"687 type of method; it does nothing beyond allowing the client to test688 the capabilities of the server. For example, this can be used to test689 a proxy for HTTP/1.1 conformance (or lack thereof).690 </t>691 <t>692 If the request-target is not an asterisk, the OPTIONS request applies693 only to the options that are available when communicating with that694 resource.695 </t>696 <t>697 A <x:ref>200 (OK)</x:ref> response &SHOULD; include any header fields that698 indicate optional features implemented by the server and applicable to that699 resource (e.g., <x:ref>Allow</x:ref>), possibly including extensions not700 defined by this specification. The response body, if any, &SHOULD; also701 include information about the communication options. The format for such a702 body is not defined by this specification, but might be defined by703 future extensions to HTTP. Content negotiation &MAY; be used to select704 the appropriate response format. If no response body is included, the705 response &MUST; include a <x:ref>Content-Length</x:ref> field with a706 field-value of "0".707 </t>708 <t>709 The <x:ref>Max-Forwards</x:ref> header field &MAY; be used to target a710 specific proxy in the request chain (see <xref target="header.max-forwards"/>).711 If no Max-Forwards field is present in the request, then the forwarded712 request &MUST-NOT; include a Max-Forwards field.713 </t>714 </section>715 716 655 <section title="GET" anchor="GET"> 717 656 <rdf:Description> … … 1014 953 </section> 1015 954 955 <section title="CONNECT" anchor="CONNECT"> 956 <iref primary="true" item="CONNECT method" x:for-anchor=""/> 957 <iref primary="true" item="Methods" subitem="CONNECT" x:for-anchor=""/> 958 <t> 959 The CONNECT method requests that the proxy establish a tunnel 960 to the request-target and, if successful, thereafter restrict its behavior 961 to blind forwarding of packets until the connection is closed. 962 </t> 963 <t> 964 When using CONNECT, the request-target &MUST; use the authority form 965 (&request-target;); i.e., the request-target consists of only the 966 host name and port number of the tunnel destination, separated by a colon. 967 For example, 968 </t> 969 <figure><artwork type="message/http; msgtype="request"" x:indent-with=" "> 970 CONNECT server.example.com:80 HTTP/1.1 971 Host: server.example.com:80 972 973 </artwork></figure> 974 <t> 975 Any <x:ref>2xx (Successful)</x:ref> response to a CONNECT request indicates that the 976 proxy has established a connection to the requested host and port, 977 and has switched to tunneling the current connection to that server 978 connection. 979 The tunneled data from the server begins immediately after the blank line 980 that concludes the successful response's header block. 981 </t> 982 <t> 983 A server &SHOULD-NOT; send any <x:ref>Transfer-Encoding</x:ref> or 984 <x:ref>Content-Length</x:ref> header fields in a successful response. 985 A client &MUST; ignore any Content-Length or Transfer-Encoding header 986 fields received in a successful response. 987 </t> 988 <t> 989 Any response other than a successful response indicates that the tunnel 990 has not yet been formed and that the connection remains governed by HTTP. 991 </t> 992 <t> 993 Proxy authentication might be used to establish the 994 authority to create a tunnel: 995 </t> 996 <figure><artwork type="message/http; msgtype="request"" x:indent-with=" "> 997 CONNECT server.example.com:80 HTTP/1.1 998 Host: server.example.com:80 999 Proxy-Authorization: basic aGVsbG86d29ybGQ= 1000 1001 </artwork></figure> 1002 <t> 1003 A message body on a CONNECT request has no defined semantics. Sending a 1004 body on a CONNECT request might cause existing implementations to reject 1005 the request. 1006 </t> 1007 <t> 1008 Similar to a pipelined HTTP/1.1 request, data to be tunneled from client 1009 to server &MAY; be sent immediately after the request (before a response 1010 is received). The usual caveats also apply: 1011 data can be discarded if the eventual response is negative, and the 1012 connection can be reset with no response if more than one TCP segment 1013 is outstanding. 1014 </t> 1015 <t> 1016 It might be the case that the proxy itself can only reach the requested 1017 origin server through another proxy. In this case, the first proxy 1018 &SHOULD; make a CONNECT request of that next proxy, requesting a tunnel 1019 to the authority. A proxy &MUST-NOT; respond with any <x:ref>2xx</x:ref> status code 1020 unless it has either a direct or tunnel connection established to the 1021 authority. 1022 </t> 1023 <t> 1024 If at any point either one of the peers gets disconnected, any 1025 outstanding data that came from that peer will be passed to the other 1026 one, and after that also the other connection will be terminated by 1027 the proxy. If there is outstanding data to that peer undelivered, 1028 that data will be discarded. 1029 </t> 1030 <t> 1031 An origin server which receives a CONNECT request for itself &MAY; 1032 respond with a <x:ref>2xx</x:ref> status code to indicate that a connection is 1033 established. However, most origin servers do not implement CONNECT. 1034 </t> 1035 </section> 1036 1037 <section title="OPTIONS" anchor="OPTIONS"> 1038 <rdf:Description> 1039 <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe> 1040 <idempotent xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</idempotent> 1041 </rdf:Description> 1042 <iref primary="true" item="OPTIONS method" x:for-anchor=""/> 1043 <iref primary="true" item="Methods" subitem="OPTIONS" x:for-anchor=""/> 1044 <t> 1045 The OPTIONS method requests information about the 1046 communication options available on the request/response chain 1047 identified by the effective request URI. This method allows a client to 1048 determine the options and/or requirements associated with a resource, 1049 or the capabilities of a server, without implying a resource action 1050 or initiating a resource retrieval. 1051 </t> 1052 <t> 1053 Responses to the OPTIONS method are not cacheable. 1054 </t> 1055 <t> 1056 If the OPTIONS request includes a message body (as indicated by the 1057 presence of <x:ref>Content-Length</x:ref> or <x:ref>Transfer-Encoding</x:ref>), 1058 then the media type &MUST; be indicated by a <x:ref>Content-Type</x:ref> 1059 field. Although this specification does not define any use for such a body, 1060 future extensions to HTTP might use the OPTIONS body to make more detailed 1061 queries on the server. 1062 </t> 1063 <t> 1064 If the request-target (&request-target;) is an asterisk ("*"), 1065 the OPTIONS request is 1066 intended to apply to the server in general rather than to a specific 1067 resource. Since a server's communication options typically depend on 1068 the resource, the "*" request is only useful as a "ping" or "no-op" 1069 type of method; it does nothing beyond allowing the client to test 1070 the capabilities of the server. For example, this can be used to test 1071 a proxy for HTTP/1.1 conformance (or lack thereof). 1072 </t> 1073 <t> 1074 If the request-target is not an asterisk, the OPTIONS request applies 1075 only to the options that are available when communicating with that 1076 resource. 1077 </t> 1078 <t> 1079 A <x:ref>200 (OK)</x:ref> response &SHOULD; include any header fields that 1080 indicate optional features implemented by the server and applicable to that 1081 resource (e.g., <x:ref>Allow</x:ref>), possibly including extensions not 1082 defined by this specification. The response body, if any, &SHOULD; also 1083 include information about the communication options. The format for such a 1084 body is not defined by this specification, but might be defined by 1085 future extensions to HTTP. Content negotiation &MAY; be used to select 1086 the appropriate response format. If no response body is included, the 1087 response &MUST; include a <x:ref>Content-Length</x:ref> field with a 1088 field-value of "0". 1089 </t> 1090 <t> 1091 The <x:ref>Max-Forwards</x:ref> header field &MAY; be used to target a 1092 specific proxy in the request chain (see <xref target="header.max-forwards"/>). 1093 If no Max-Forwards field is present in the request, then the forwarded 1094 request &MUST-NOT; include a Max-Forwards field. 1095 </t> 1096 </section> 1097 1016 1098 <section title="TRACE" anchor="TRACE"> 1017 1099 <rdf:Description> … … 1046 1128 </t> 1047 1129 </section> 1048 1049 <section title="CONNECT" anchor="CONNECT"> 1050 <iref primary="true" item="CONNECT method" x:for-anchor=""/> 1051 <iref primary="true" item="Methods" subitem="CONNECT" x:for-anchor=""/> 1052 <t> 1053 The CONNECT method requests that the proxy establish a tunnel 1054 to the request-target and, if successful, thereafter restrict its behavior 1055 to blind forwarding of packets until the connection is closed. 1056 </t> 1057 <t> 1058 When using CONNECT, the request-target &MUST; use the authority form 1059 (&request-target;); i.e., the request-target consists of only the 1060 host name and port number of the tunnel destination, separated by a colon. 1061 For example, 1062 </t> 1063 <figure><artwork type="message/http; msgtype="request"" x:indent-with=" "> 1064 CONNECT server.example.com:80 HTTP/1.1 1065 Host: server.example.com:80 1066 1067 </artwork></figure> 1068 <t> 1069 Any <x:ref>2xx (Successful)</x:ref> response to a CONNECT request indicates that the 1070 proxy has established a connection to the requested host and port, 1071 and has switched to tunneling the current connection to that server 1072 connection. 1073 The tunneled data from the server begins immediately after the blank line 1074 that concludes the successful response's header block. 1075 </t> 1076 <t> 1077 A server &SHOULD-NOT; send any <x:ref>Transfer-Encoding</x:ref> or 1078 <x:ref>Content-Length</x:ref> header fields in a successful response. 1079 A client &MUST; ignore any Content-Length or Transfer-Encoding header 1080 fields received in a successful response. 1081 </t> 1082 <t> 1083 Any response other than a successful response indicates that the tunnel 1084 has not yet been formed and that the connection remains governed by HTTP. 1085 </t> 1086 <t> 1087 Proxy authentication might be used to establish the 1088 authority to create a tunnel: 1089 </t> 1090 <figure><artwork type="message/http; msgtype="request"" x:indent-with=" "> 1091 CONNECT server.example.com:80 HTTP/1.1 1092 Host: server.example.com:80 1093 Proxy-Authorization: basic aGVsbG86d29ybGQ= 1094 1095 </artwork></figure> 1096 <t> 1097 A message body on a CONNECT request has no defined semantics. Sending a 1098 body on a CONNECT request might cause existing implementations to reject 1099 the request. 1100 </t> 1101 <t> 1102 Similar to a pipelined HTTP/1.1 request, data to be tunneled from client 1103 to server &MAY; be sent immediately after the request (before a response 1104 is received). The usual caveats also apply: 1105 data can be discarded if the eventual response is negative, and the 1106 connection can be reset with no response if more than one TCP segment 1107 is outstanding. 1108 </t> 1109 <t> 1110 It might be the case that the proxy itself can only reach the requested 1111 origin server through another proxy. In this case, the first proxy 1112 &SHOULD; make a CONNECT request of that next proxy, requesting a tunnel 1113 to the authority. A proxy &MUST-NOT; respond with any <x:ref>2xx</x:ref> status code 1114 unless it has either a direct or tunnel connection established to the 1115 authority. 1116 </t> 1117 <t> 1118 If at any point either one of the peers gets disconnected, any 1119 outstanding data that came from that peer will be passed to the other 1120 one, and after that also the other connection will be terminated by 1121 the proxy. If there is outstanding data to that peer undelivered, 1122 that data will be discarded. 1123 </t> 1124 <t> 1125 An origin server which receives a CONNECT request for itself &MAY; 1126 respond with a <x:ref>2xx</x:ref> status code to indicate that a connection is 1127 established. However, most origin servers do not implement CONNECT. 1128 </t> 1129 </section> 1130 </section> 1131 1130 </section> 1132 1131 </section> 1133 1132
Note: See TracChangeset
for help on using the changeset viewer.
