Changeset 1309 for draft-ietf-httpbis/latest
- Timestamp:
- 22/06/11 06:49:40 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 4 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1306 r1309 359 359 } 360 360 @bottom-center { 361 content: "Expires December 10, 2011";361 content: "Expires December 24, 2011"; 362 362 } 363 363 @bottom-right { … … 410 410 <meta name="dct.creator" content="Reschke, J. F."> 411 411 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 412 <meta name="dct.issued" scheme="ISO8601" content="2011-06- 08">412 <meta name="dct.issued" scheme="ISO8601" content="2011-06-22"> 413 413 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 414 414 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 442 442 </tr> 443 443 <tr> 444 <td class="left">Expires: December 10, 2011</td>444 <td class="left">Expires: December 24, 2011</td> 445 445 <td class="right">HP</td> 446 446 </tr> … … 495 495 <tr> 496 496 <td class="left"></td> 497 <td class="right">June 8, 2011</td>497 <td class="right">June 22, 2011</td> 498 498 </tr> 499 499 </tbody> … … 525 525 in progress”. 526 526 </p> 527 <p>This Internet-Draft will expire on December 10, 2011.</p>527 <p>This Internet-Draft will expire on December 24, 2011.</p> 528 528 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 529 529 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 967 967 or an intranet-to-Internet privacy filter. Such transformations are presumed to be desired by the client (or client organization) 968 968 that selected the proxy and are beyond the scope of this specification. However, when a proxy is not intended to transform 969 a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics. 969 a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics. See <a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 8.2.4</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> for status and warning codes related to transformations. 970 970 </p> 971 971 <p id="rfc.section.2.3.p.7"><span id="rfc.iref.g.24"></span><span id="rfc.iref.r.4"></span> <span id="rfc.iref.a.1"></span> A "<dfn>gateway</dfn>" (a.k.a., "<dfn>reverse proxy</dfn>") is a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying … … 1006 1006 </pre><p id="rfc.section.2.4.p.4"><span id="rfc.iref.c.5"></span> A response is "<dfn>cacheable</dfn>" if a cache is allowed to store a copy of the response message for use in answering subsequent requests. Even when a response 1007 1007 is cacheable, there might be additional constraints placed by the client or by the origin server on when that cached response 1008 can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are defined in <a href="p6-cache.html#caching.overview" title="Cache Operation">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6. 1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.1008 can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are defined in <a href="p6-cache.html#caching.overview" title="Cache Operation">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 1009 1009 </p> 1010 1010 <p id="rfc.section.2.4.p.5">There are a wide variety of architectures and configurations of caches and proxies deployed across the World Wide Web and … … 1144 1144 <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.35"></span> <a href="#https.uri" class="smpl">https-URI</a> = "https:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ] 1145 1145 </pre><p id="rfc.section.2.6.2.p.4">Unlike the "http" scheme, responses to "https" identified requests are never "public" and thus <em class="bcp14">MUST NOT</em> be reused for shared caching. They can, however, be reused in a private cache if the message is cacheable by default in HTTP 1146 or specifically indicated as such by the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6. 2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).1146 or specifically indicated as such by the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1147 1147 </p> 1148 1148 <p id="rfc.section.2.6.2.p.5">Resources made available via the "https" scheme have no shared identity with the "http" scheme even if their resource identifiers … … 1351 1351 <p id="rfc.section.3.3.p.15">Request messages that are prematurely terminated, possibly due to a cancelled connection or a server-imposed time-out exception, <em class="bcp14">MUST</em> result in closure of the connection; sending an HTTP/1.1 error response prior to closing the connection is <em class="bcp14">OPTIONAL</em>. Response messages that are prematurely terminated, usually by closure of the connection prior to receiving the expected 1352 1352 number of octets or by failure to decode a transfer-encoded message-body, <em class="bcp14">MUST</em> be recorded as incomplete. A user agent <em class="bcp14">MUST NOT</em> render an incomplete response message-body as if it were complete (i.e., some indication must be given to the user that an 1353 error occurred). Cache requirements for incomplete responses are defined in <a href="p6-cache.html#errors.or.incomplete.response.cache.behavior" title="Storing Partial and Incomplete Responses">Section 2.1.1</a> of <a href="#Part6" id="rfc.xref.Part6. 3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.1353 error occurred). Cache requirements for incomplete responses are defined in <a href="p6-cache.html#errors.or.incomplete.response.cache.behavior" title="Storing Partial and Incomplete Responses">Section 2.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 1354 1354 </p> 1355 1355 <p id="rfc.section.3.3.p.16">A server <em class="bcp14">MUST</em> read the entire request message-body or close the connection after sending its response, since otherwise the remaining data … … 1437 1437 <p id="rfc.section.4.1.2.p.9">If a proxy receives a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name. 1438 1438 </p> 1439 <p id="rfc.section.4.1.2.p.10"><span id="rfc.iref.a.4"></span> The "authority form" is only used by the CONNECT request method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 7.9</a> of <a href="#Part2" id="rfc.xref.Part2. 1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).1439 <p id="rfc.section.4.1.2.p.10"><span id="rfc.iref.a.4"></span> The "authority form" is only used by the CONNECT request method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 7.9</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1440 1440 </p> 1441 1441 <p id="rfc.section.4.1.2.p.11"><span id="rfc.iref.o.3"></span> The most common form of request-target is that used when making a request to an origin server ("origin form"). In this case, … … 1470 1470 </div> 1471 1471 <p id="rfc.section.4.1.2.p.20">HTTP does not place a pre-defined limit on the length of a request-target. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI Too Long) status code if the received request-target 1472 would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 8.4.15</a> of <a href="#Part2" id="rfc.xref.Part2. 2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).1472 would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 8.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1473 1473 </p> 1474 1474 <p id="rfc.section.4.1.2.p.21">Various ad-hoc limitations on request-target length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support request-target lengths of 8000 or more octets. … … 1551 1551 </pre><h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a> <a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h3> 1552 1552 <p id="rfc.section.5.1.1.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. These codes 1553 are fully defined in <a href="p2-semantics.html#status.codes" title="Status Code Definitions">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2. 3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. The Reason Phrase exists for the sole purpose of providing a textual description associated with the numeric status code,1553 are fully defined in <a href="p2-semantics.html#status.codes" title="Status Code Definitions">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. The Reason Phrase exists for the sole purpose of providing a textual description associated with the numeric status code, 1554 1554 out of deference to earlier Internet application protocols that were more frequently used with interactive text clients. A 1555 1555 client <em class="bcp14">SHOULD</em> ignore the content of the Reason Phrase. … … 1874 1874 <p id="rfc.section.7.1.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses. 1875 1875 </p> 1876 <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2. 4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to1876 <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to 1877 1877 send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request. 1878 1878 </p> … … 1937 1937 <li>Content-Type</li> 1938 1938 </ul> 1939 <p id="rfc.section.7.1.3.2.p.6">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6. 4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).1939 <p id="rfc.section.7.1.3.2.p.6">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1940 1940 </p> 1941 1941 <div class="note" id="rfc.section.7.1.3.2.p.7"> … … 1960 1960 </p> 1961 1961 <p id="rfc.section.7.1.4.p.4">This means that clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">SHOULD</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request 1962 sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2. 5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding1962 sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding 1963 1963 of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails. 1964 1964 </p> … … 1987 1987 </p> 1988 1988 <h3 id="rfc.section.7.2.3"><a href="#rfc.section.7.2.3">7.2.3</a> <a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3> 1989 <p id="rfc.section.7.2.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 8.1.1</a> of <a href="#Part2" id="rfc.xref.Part2. 6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing1989 <p id="rfc.section.7.2.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 8.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing 1990 1990 to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might 1991 1991 either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without … … 1994 1994 <p id="rfc.section.7.2.3.p.2">Requirements for HTTP/1.1 clients: </p> 1995 1995 <ul> 1996 <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2. 7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.1997 </li> 1998 <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2. 8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.1996 <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation. 1997 </li> 1998 <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body. 1999 1999 </li> 2000 2000 </ul> … … 2040 2040 <li>A proxy <em class="bcp14">MUST NOT</em> forward a 100 (Continue) response if the request message was received from an HTTP/1.0 (or earlier) client and did not include 2041 2041 an Expect header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of 2042 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 8.1</a> of <a href="#Part2" id="rfc.xref.Part2. 9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).2042 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 8.1</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 2043 2043 </li> 2044 2044 </ul> … … 2104 2104 </p> 2105 2105 <p id="rfc.section.9.1.p.5">A sender <em class="bcp14">MUST NOT</em> include field-names in the Connection header field-value for fields that are defined as expressing constraints for all recipients 2106 in the request or response chain, such as the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6. 5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).2106 in the request or response chain, such as the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 2107 2107 </p> 2108 2108 <p id="rfc.section.9.1.p.6">The connection options do not have to correspond to a header field present in the message, since a connection-specific header … … 2316 2316 </p> 2317 2317 <p id="rfc.section.9.8.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it 2318 is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 8.3</a> of <a href="#Part2" id="rfc.xref.Part2.1 0"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).2318 is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 8.3</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 2319 2319 </p> 2320 2320 <p id="rfc.section.9.8.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in 101 (Switching Protocols) responses to indicate which protocol(s) are being switched … … 3800 3800 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3801 3801 <li><em>Pad1995</em> <a href="#rfc.xref.Pad1995.1">7.1.1</a>, <a href="#Pad1995"><b>13.2</b></a></li> 3802 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">4.1.2</a>, <a href="#rfc.xref.Part2.2">4.1.2</a>, <a href="#rfc.xref.Part2.3">5.1.1</a>, <a href="#rfc.xref.Part2.4">7.1.2.2</a>, <a href="#rfc.xref.Part2.5">7.1.4</a>, <a href="#rfc.xref.Part2.6">7.2.3</a>, <a href="#rfc.xref.Part2.7">7.2.3</a>, <a href="#rfc.xref.Part2.8">7.2.3</a>, <a href="#rfc.xref.Part2.9">7.2.3</a>, <a href="#rfc.xref.Part2.10">9.8</a>, <a href="#Part2"><b>13.1</b></a><ul> 3803 <li><em>Section 7.1.2</em> <a href="#rfc.xref.Part2.4">7.1.2.2</a>, <a href="#rfc.xref.Part2.5">7.1.4</a></li> 3804 <li><em>Section 7.9</em> <a href="#rfc.xref.Part2.1">4.1.2</a></li> 3805 <li><em>Section 8</em> <a href="#rfc.xref.Part2.3">5.1.1</a></li> 3806 <li><em>Section 8.1.1</em> <a href="#rfc.xref.Part2.6">7.2.3</a></li> 3807 <li><em>Section 8.1</em> <a href="#rfc.xref.Part2.9">7.2.3</a></li> 3808 <li><em>Section 8.3</em> <a href="#rfc.xref.Part2.10">9.8</a></li> 3809 <li><em>Section 8.4.15</em> <a href="#rfc.xref.Part2.2">4.1.2</a></li> 3810 <li><em>Section 9.2</em> <a href="#rfc.xref.Part2.7">7.2.3</a>, <a href="#rfc.xref.Part2.8">7.2.3</a></li> 3802 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">2.3</a>, <a href="#rfc.xref.Part2.2">4.1.2</a>, <a href="#rfc.xref.Part2.3">4.1.2</a>, <a href="#rfc.xref.Part2.4">5.1.1</a>, <a href="#rfc.xref.Part2.5">7.1.2.2</a>, <a href="#rfc.xref.Part2.6">7.1.4</a>, <a href="#rfc.xref.Part2.7">7.2.3</a>, <a href="#rfc.xref.Part2.8">7.2.3</a>, <a href="#rfc.xref.Part2.9">7.2.3</a>, <a href="#rfc.xref.Part2.10">7.2.3</a>, <a href="#rfc.xref.Part2.11">9.8</a>, <a href="#Part2"><b>13.1</b></a><ul> 3803 <li><em>Section 7.1.2</em> <a href="#rfc.xref.Part2.5">7.1.2.2</a>, <a href="#rfc.xref.Part2.6">7.1.4</a></li> 3804 <li><em>Section 7.9</em> <a href="#rfc.xref.Part2.2">4.1.2</a></li> 3805 <li><em>Section 8</em> <a href="#rfc.xref.Part2.4">5.1.1</a></li> 3806 <li><em>Section 8.1.1</em> <a href="#rfc.xref.Part2.7">7.2.3</a></li> 3807 <li><em>Section 8.1</em> <a href="#rfc.xref.Part2.10">7.2.3</a></li> 3808 <li><em>Section 8.2.4</em> <a href="#rfc.xref.Part2.1">2.3</a></li> 3809 <li><em>Section 8.3</em> <a href="#rfc.xref.Part2.11">9.8</a></li> 3810 <li><em>Section 8.4.15</em> <a href="#rfc.xref.Part2.3">4.1.2</a></li> 3811 <li><em>Section 9.2</em> <a href="#rfc.xref.Part2.8">7.2.3</a>, <a href="#rfc.xref.Part2.9">7.2.3</a></li> 3811 3812 </ul> 3812 3813 </li> … … 3817 3818 </ul> 3818 3819 </li> 3819 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">2. 4</a>, <a href="#rfc.xref.Part6.2">2.6.2</a>, <a href="#rfc.xref.Part6.3">3.3</a>, <a href="#rfc.xref.Part6.4">7.1.3.2</a>, <a href="#rfc.xref.Part6.5">9.1</a>, <a href="#Part6"><b>13.1</b></a><ul>3820 <li><em>Section 2</em> <a href="#rfc.xref.Part6. 1">2.4</a></li>3821 <li><em>Section 2.1.1</em> <a href="#rfc.xref.Part6. 3">3.3</a></li>3822 <li><em>Section 3.2</em> <a href="#rfc.xref.Part6. 2">2.6.2</a>, <a href="#rfc.xref.Part6.5">9.1</a></li>3823 <li><em>Section 3.6</em> <a href="#rfc.xref.Part6. 4">7.1.3.2</a></li>3820 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">2.3</a>, <a href="#rfc.xref.Part6.2">2.4</a>, <a href="#rfc.xref.Part6.3">2.6.2</a>, <a href="#rfc.xref.Part6.4">3.3</a>, <a href="#rfc.xref.Part6.5">7.1.3.2</a>, <a href="#rfc.xref.Part6.6">9.1</a>, <a href="#Part6"><b>13.1</b></a><ul> 3821 <li><em>Section 2</em> <a href="#rfc.xref.Part6.2">2.4</a></li> 3822 <li><em>Section 2.1.1</em> <a href="#rfc.xref.Part6.4">3.3</a></li> 3823 <li><em>Section 3.2</em> <a href="#rfc.xref.Part6.3">2.6.2</a>, <a href="#rfc.xref.Part6.6">9.1</a></li> 3824 <li><em>Section 3.6</em> <a href="#rfc.xref.Part6.1">2.3</a>, <a href="#rfc.xref.Part6.5">7.1.3.2</a></li> 3824 3825 </ul> 3825 3826 </li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1306 r1309 34 34 <!ENTITY status-100 "<xref target='Part2' x:rel='#status.100' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 35 35 <!ENTITY status-1xx "<xref target='Part2' x:rel='#status.1xx' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 36 <!ENTITY status-203 "<xref target='Part2' x:rel='#status.203' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 36 37 <!ENTITY status-3xx "<xref target='Part2' x:rel='#status.3xx' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 37 38 <!ENTITY status-414 "<xref target='Part2' x:rel='#status.414' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 710 711 this specification. However, when a proxy is not intended to transform 711 712 a given message, we use the term "<x:dfn>non-transforming proxy</x:dfn>" to target 712 requirements that preserve HTTP message semantics. 713 requirements that preserve HTTP message semantics. See &status-203; and 714 &header-warning; for status and warning codes related to transformations. 713 715 </t> 714 716 <t><iref primary="true" item="gateway"/><iref primary="true" item="reverse proxy"/> -
draft-ietf-httpbis/latest/p2-semantics.html
r1303 r1309 359 359 } 360 360 @bottom-center { 361 content: "Expires December 3, 2011";361 content: "Expires December 24, 2011"; 362 362 } 363 363 @bottom-right { … … 409 409 <meta name="dct.creator" content="Reschke, J. F."> 410 410 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 411 <meta name="dct.issued" scheme="ISO8601" content="2011-06- 01">411 <meta name="dct.issued" scheme="ISO8601" content="2011-06-22"> 412 412 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 413 413 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields."> … … 440 440 </tr> 441 441 <tr> 442 <td class="left">Expires: December 3, 2011</td>442 <td class="left">Expires: December 24, 2011</td> 443 443 <td class="right">HP</td> 444 444 </tr> … … 493 493 <tr> 494 494 <td class="left"></td> 495 <td class="right">June 1, 2011</td>495 <td class="right">June 22, 2011</td> 496 496 </tr> 497 497 </tbody> … … 522 522 in progress”. 523 523 </p> 524 <p>This Internet-Draft will expire on December 3, 2011.</p>524 <p>This Internet-Draft will expire on December 24, 2011.</p> 525 525 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 526 526 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1601 1601 <div id="rfc.iref.s.7"></div> 1602 1602 <h3 id="rfc.section.8.2.4"><a href="#rfc.section.8.2.4">8.2.4</a> <a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3> 1603 <p id="rfc.section.8.2.4.p.1">The re turned metadata in the header fields is not the definitive set as available from the origin server, but is gathered1604 from a local or a third-party copy. The set presented <em class="bcp14">MAY</em> be a subset or superset of the original version. For example, including local annotation information about the resource might1605 result in a superset of the metadata known by the origin server. Use of this response code is not required and is only appropriate1606 when the response would otherwise be 200 (OK).1607 </p> 1608 <p id="rfc.section.8.2.4.p. 2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 203 responses.1603 <p id="rfc.section.8.2.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.3</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Note that the behaviour of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1604 </p> 1605 <p id="rfc.section.8.2.4.p.2">This status code is only appropriate when the response status code would have been 200 (OK) otherwise. When the status code 1606 before transformation would have been different, the 214 Transformation Applied warn-code (<a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.13"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) is appropriate. 1607 </p> 1608 <p id="rfc.section.8.2.4.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.14"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 203 responses. 1609 1609 </p> 1610 1610 <div id="rfc.iref.28"></div> … … 1636 1636 another input action. 1637 1637 </p> 1638 <p id="rfc.section.8.2.6.p.2">The message-body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.2 7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.1638 <p id="rfc.section.8.2.6.p.2">The message-body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 1639 1639 </p> 1640 1640 <div id="rfc.iref.30"></div> … … 1644 1644 defined in <a href="p5-range.html#status.206" title="206 Partial Content">Section 3.1</a> of <a href="#Part5" id="rfc.xref.Part5.8"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. 1645 1645 </p> 1646 <p id="rfc.section.8.2.7.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.1 3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 206 responses.1646 <p id="rfc.section.8.2.7.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.15"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 206 responses. 1647 1647 </p> 1648 1648 <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a> <a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2> … … 1668 1668 <p id="rfc.section.8.3.1.p.3">If the server has a preferred choice of representation, it <em class="bcp14">SHOULD</em> include the specific URI for that representation in the Location field; user agents <em class="bcp14">MAY</em> use the Location field value for automatic redirection. 1669 1669 </p> 1670 <p id="rfc.section.8.3.1.p.4">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.1 4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 300 responses.1670 <p id="rfc.section.8.3.1.p.4">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.16"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 300 responses. 1671 1671 </p> 1672 1672 <div id="rfc.iref.32"></div> … … 1676 1676 request URI to one or more of the new references returned by the server, where possible. 1677 1677 </p> 1678 <p id="rfc.section.8.3.2.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.1 5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 301 responses.1678 <p id="rfc.section.8.3.2.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.17"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 301 responses. 1679 1679 </p> 1680 1680 <p id="rfc.section.8.3.2.p.3">The new permanent URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the representation of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s). … … 1850 1850 — that is left to the discretion of the server owner. 1851 1851 </p> 1852 <p id="rfc.section.8.4.11.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.1 6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 410 responses.1852 <p id="rfc.section.8.4.11.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.18"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 410 responses. 1853 1853 </p> 1854 1854 <div id="rfc.iref.50"></div> … … 1901 1901 <div id="rfc.iref.s.37"></div> 1902 1902 <h3 id="rfc.section.8.4.19"><a href="#rfc.section.8.4.19">8.4.19</a> <a id="status.426" href="#status.426">426 Upgrade Required</a></h3> 1903 <p id="rfc.section.8.4.19.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an Upgrade header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 9.8</a> of <a href="#Part1" id="rfc.xref.Part1.2 8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols.1903 <p id="rfc.section.8.4.19.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an Upgrade header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 9.8</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols. 1904 1904 </p> 1905 1905 <div id="rfc.figure.u.7"></div> … … 1958 1958 <p id="rfc.section.8.5.6.p.1">The server does not support, or refuses to support, the protocol version that was used in the request message. The server 1959 1959 is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described 1960 in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.5</a> of <a href="#Part1" id="rfc.xref.Part1. 29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server.1960 in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.5</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server. 1961 1961 </p> 1962 1962 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> … … 1998 1998 </p> 1999 1999 <p id="rfc.section.9.2.p.7">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p> 2000 <p id="rfc.section.9.2.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.3 0"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status code.2000 <p id="rfc.section.9.2.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status code. 2001 2001 </p> 2002 2002 <div id="rfc.iref.f.1"></div> … … 2102 2102 <h2 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a> <a id="header.server" href="#header.server">Server</a></h2> 2103 2103 <p id="rfc.section.9.8.p.1">The "Server" header field contains information about the software used by the origin server to handle the request.</p> 2104 <p id="rfc.section.9.8.p.2">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.3 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for2104 <p id="rfc.section.9.8.p.2">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for 2105 2105 identifying the application. 2106 2106 </p> … … 2108 2108 </pre><p id="rfc.section.9.8.p.4">Example:</p> 2109 2109 <div id="rfc.figure.u.23"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 2110 </pre><p id="rfc.section.9.8.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.3 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).2110 </pre><p id="rfc.section.9.8.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 2111 2111 </p> 2112 2112 <div class="note" id="rfc.section.9.8.p.7"> … … 2124 2124 user agent limitations. 2125 2125 </p> 2126 <p id="rfc.section.9.9.p.3">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.3 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance2126 <p id="rfc.section.9.9.p.3">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance 2127 2127 for identifying the application. 2128 2128 </p> … … 2711 2711 <p id="rfc.section.A.p.4">Take over definition of CONNECT method from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#CONNECT" id="rfc.xref.CONNECT.3" title="CONNECT">Section 7.9</a>) 2712 2712 </p> 2713 <p id="rfc.section.A.p.5">Failed to consider that there are many other request methods that are safe to automatically redirect, and further that the 2713 <p id="rfc.section.A.p.5">Broadened the definition of 203 (Non-Authoritative Information) to include cases of payload transformations as well. (<a href="#status.203" id="rfc.xref.status.203.3" title="203 Non-Authoritative Information">Section 8.2.4</a>) 2714 </p> 2715 <p id="rfc.section.A.p.6">Failed to consider that there are many other request methods that are safe to automatically redirect, and further that the 2714 2716 user agent is able to make that determination based on the request method semantics. (Sections <a href="#status.301" id="rfc.xref.status.301.3" title="301 Moved Permanently">8.3.2</a>, <a href="#status.302" id="rfc.xref.status.302.3" title="302 Found">8.3.3</a> and <a href="#status.307" id="rfc.xref.status.307.4" title="307 Temporary Redirect">8.3.8</a>) 2715 2717 </p> 2716 <p id="rfc.section.A.p. 6">Deprecate 305 Use Proxy status code, because user agents did not implement it. It used to indicate that the target resource2718 <p id="rfc.section.A.p.7">Deprecate 305 Use Proxy status code, because user agents did not implement it. It used to indicate that the target resource 2717 2719 must be accessed through the proxy given by the Location field. The Location field gave the URI of the proxy. The recipient 2718 2720 was expected to repeat this single request via the proxy. (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section 8.3.6</a>) 2719 2721 </p> 2720 <p id="rfc.section.A.p. 7">Define status 426 (Upgrade Required) (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#status.426" id="rfc.xref.status.426.3" title="426 Upgrade Required">Section 8.4.19</a>)2721 </p> 2722 <p id="rfc.section.A.p. 8">Change ABNF productions for header fields to only define the field value. (<a href="#header.fields" title="Header Field Definitions">Section 9</a>)2723 </p> 2724 <p id="rfc.section.A.p. 9">Reclassify "Allow" as response header field, removing the option to specify it in a PUT request. Relax the server requirement2722 <p id="rfc.section.A.p.8">Define status 426 (Upgrade Required) (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#status.426" id="rfc.xref.status.426.3" title="426 Upgrade Required">Section 8.4.19</a>) 2723 </p> 2724 <p id="rfc.section.A.p.9">Change ABNF productions for header fields to only define the field value. (<a href="#header.fields" title="Header Field Definitions">Section 9</a>) 2725 </p> 2726 <p id="rfc.section.A.p.10">Reclassify "Allow" as response header field, removing the option to specify it in a PUT request. Relax the server requirement 2725 2727 on the contents of the Allow header field and remove requirement on clients to always trust the header field value. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section 9.1</a>) 2726 2728 </p> 2727 <p id="rfc.section.A.p.1 0">Correct syntax of Location header field to allow URI references (including relative references and fragments), as referred2729 <p id="rfc.section.A.p.11">Correct syntax of Location header field to allow URI references (including relative references and fragments), as referred 2728 2730 symbol "absoluteURI" wasn't what was expected, and add some clarifications as to when use of fragments would not be appropriate. 2729 2731 (<a href="#header.location" id="rfc.xref.header.location.4" title="Location">Section 9.4</a>) 2730 2732 </p> 2731 <p id="rfc.section.A.p.1 1">Restrict Max-Forwards header field to OPTIONS and TRACE (previously, extension methods could have used it as well). (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section 9.5</a>)2732 </p> 2733 <p id="rfc.section.A.p.1 2">Allow Referer field value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section 9.6</a>)2734 </p> 2735 <p id="rfc.section.A.p.1 3">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated2736 correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.3 6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 9.8</a>)2733 <p id="rfc.section.A.p.12">Restrict Max-Forwards header field to OPTIONS and TRACE (previously, extension methods could have used it as well). (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section 9.5</a>) 2734 </p> 2735 <p id="rfc.section.A.p.13">Allow Referer field value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section 9.6</a>) 2736 </p> 2737 <p id="rfc.section.A.p.14">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated 2738 correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.37"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 9.8</a>) 2737 2739 </p> 2738 2740 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> … … 3048 3050 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/294">http://tools.ietf.org/wg/httpbis/trac/ticket/294</a>>: "clarify 403 forbidden" 3049 3051 </li> 3052 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/296">http://tools.ietf.org/wg/httpbis/trac/ticket/296</a>>: "Clarify 203 Non-Authoritative Information" 3053 </li> 3050 3054 </ul> 3051 3055 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> … … 3063 3067 <li>201 Created (status code) <a href="#rfc.xref.status.201.1">4.1</a>, <a href="#rfc.iref.25"><b>8.2.2</b></a>, <a href="#rfc.xref.status.201.2">10.2</a></li> 3064 3068 <li>202 Accepted (status code) <a href="#rfc.xref.status.202.1">4.1</a>, <a href="#rfc.iref.26"><b>8.2.3</b></a>, <a href="#rfc.xref.status.202.2">10.2</a></li> 3065 <li>203 Non-Authoritative Information (status code) <a href="#rfc.xref.status.203.1">4.1</a>, <a href="#rfc.iref.27"><b>8.2.4</b></a>, <a href="#rfc.xref.status.203.2">10.2</a> </li>3069 <li>203 Non-Authoritative Information (status code) <a href="#rfc.xref.status.203.1">4.1</a>, <a href="#rfc.iref.27"><b>8.2.4</b></a>, <a href="#rfc.xref.status.203.2">10.2</a>, <a href="#rfc.xref.status.203.3">A</a></li> 3066 3070 <li>204 No Content (status code) <a href="#rfc.xref.status.204.1">4.1</a>, <a href="#rfc.iref.28"><b>8.2.5</b></a>, <a href="#rfc.xref.status.204.2">10.2</a></li> 3067 3071 <li>205 Reset Content (status code) <a href="#rfc.xref.status.205.1">4.1</a>, <a href="#rfc.iref.29"><b>8.2.6</b></a>, <a href="#rfc.xref.status.205.2">10.2</a></li> … … 3202 3206 </li> 3203 3207 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3204 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">1.2.1</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a>, <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.2</a>, <a href="#rfc.xref.Part1.10">1.2.2</a>, <a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.14">1.2.2</a>, <a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.17">3</a>, <a href="#rfc.xref.Part1.18">3</a>, <a href="#rfc.xref.Part1.19">5</a>, <a href="#rfc.xref.Part1.20">6</a>, <a href="#rfc.xref.Part1.21">6.1</a>, <a href="#rfc.xref.Part1.22">7.8</a>, <a href="#rfc.xref.Part1.23">7.8</a>, <a href="#rfc.xref.Part1.24">7.9</a>, <a href="#rfc.xref.Part1.25">8.1.1</a>, <a href="#rfc.xref.Part1.26">8.1.2</a>, <a href="#rfc.xref.Part1.27">8.2. 6</a>, <a href="#rfc.xref.Part1.28">8.4.19</a>, <a href="#rfc.xref.Part1.29">8.5.6</a>, <a href="#rfc.xref.Part1.30">9.2</a>, <a href="#rfc.xref.Part1.31">9.8</a>, <a href="#rfc.xref.Part1.32">9.8</a>, <a href="#rfc.xref.Part1.33">9.8</a>, <a href="#rfc.xref.Part1.34">9.9</a>, <a href="#rfc.xref.Part1.35">9.9</a>, <a href="#Part1"><b>13.1</b></a>, <a href="#rfc.xref.Part1.36">A</a><ul>3208 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">1.2.1</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a>, <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.2</a>, <a href="#rfc.xref.Part1.10">1.2.2</a>, <a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.14">1.2.2</a>, <a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.17">3</a>, <a href="#rfc.xref.Part1.18">3</a>, <a href="#rfc.xref.Part1.19">5</a>, <a href="#rfc.xref.Part1.20">6</a>, <a href="#rfc.xref.Part1.21">6.1</a>, <a href="#rfc.xref.Part1.22">7.8</a>, <a href="#rfc.xref.Part1.23">7.8</a>, <a href="#rfc.xref.Part1.24">7.9</a>, <a href="#rfc.xref.Part1.25">8.1.1</a>, <a href="#rfc.xref.Part1.26">8.1.2</a>, <a href="#rfc.xref.Part1.27">8.2.4</a>, <a href="#rfc.xref.Part1.28">8.2.6</a>, <a href="#rfc.xref.Part1.29">8.4.19</a>, <a href="#rfc.xref.Part1.30">8.5.6</a>, <a href="#rfc.xref.Part1.31">9.2</a>, <a href="#rfc.xref.Part1.32">9.8</a>, <a href="#rfc.xref.Part1.33">9.8</a>, <a href="#rfc.xref.Part1.34">9.8</a>, <a href="#rfc.xref.Part1.35">9.9</a>, <a href="#rfc.xref.Part1.36">9.9</a>, <a href="#Part1"><b>13.1</b></a>, <a href="#rfc.xref.Part1.37">A</a><ul> 3205 3209 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.2">1.2</a></li> 3206 3210 <li><em>Section 1.2.2</em> <a href="#rfc.xref.Part1.3">1.2.1</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a>, <a href="#rfc.xref.Part1.8">1.2.1</a></li> 3207 <li><em>Section 2.5</em> <a href="#rfc.xref.Part1.29">8.5.6</a></li> 3211 <li><em>Section 2.3</em> <a href="#rfc.xref.Part1.27">8.2.4</a></li> 3212 <li><em>Section 2.5</em> <a href="#rfc.xref.Part1.30">8.5.6</a></li> 3208 3213 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1.9">1.2.2</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.14">1.2.2</a></li> 3209 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.10">1.2.2</a>, <a href="#rfc.xref.Part1.3 2">9.8</a>, <a href="#rfc.xref.Part1.35">9.9</a></li>3210 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.20">6</a>, <a href="#rfc.xref.Part1.2 7">8.2.6</a></li>3214 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.10">1.2.2</a>, <a href="#rfc.xref.Part1.33">9.8</a>, <a href="#rfc.xref.Part1.36">9.9</a></li> 3215 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.20">6</a>, <a href="#rfc.xref.Part1.28">8.2.6</a></li> 3211 3216 <li><em>Section 4.1.2</em> <a href="#rfc.xref.Part1.24">7.9</a></li> 3212 3217 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.19">5</a>, <a href="#rfc.xref.Part1.21">6.1</a></li> 3213 3218 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.11">1.2.2</a></li> 3214 <li><em>Section 6.3</em> <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.3 1">9.8</a>, <a href="#rfc.xref.Part1.34">9.9</a></li>3215 <li><em>Section 7.2.3</em> <a href="#rfc.xref.Part1.25">8.1.1</a>, <a href="#rfc.xref.Part1.3 0">9.2</a></li>3219 <li><em>Section 6.3</em> <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.32">9.8</a>, <a href="#rfc.xref.Part1.35">9.9</a></li> 3220 <li><em>Section 7.2.3</em> <a href="#rfc.xref.Part1.25">8.1.1</a>, <a href="#rfc.xref.Part1.31">9.2</a></li> 3216 3221 <li><em>Section 9.4</em> <a href="#rfc.xref.Part1.17">3</a></li> 3217 3222 <li><em>Section 9.5</em> <a href="#rfc.xref.Part1.18">3</a></li> 3218 <li><em>Section 9.8</em> <a href="#rfc.xref.Part1.26">8.1.2</a>, <a href="#rfc.xref.Part1.2 8">8.4.19</a></li>3219 <li><em>Section 9.9</em> <a href="#rfc.xref.Part1.22">7.8</a>, <a href="#rfc.xref.Part1.3 3">9.8</a>, <a href="#rfc.xref.Part1.36">A</a></li>3223 <li><em>Section 9.8</em> <a href="#rfc.xref.Part1.26">8.1.2</a>, <a href="#rfc.xref.Part1.29">8.4.19</a></li> 3224 <li><em>Section 9.9</em> <a href="#rfc.xref.Part1.22">7.8</a>, <a href="#rfc.xref.Part1.34">9.8</a>, <a href="#rfc.xref.Part1.37">A</a></li> 3220 3225 <li><em>Section 10.3.1</em> <a href="#rfc.xref.Part1.23">7.8</a></li> 3221 3226 </ul> … … 3250 3255 </ul> 3251 3256 </li> 3252 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">2.2.1</a>, <a href="#rfc.xref.Part6.2">4.2.1</a>, <a href="#rfc.xref.Part6.3">5</a>, <a href="#rfc.xref.Part6.4">5</a>, <a href="#rfc.xref.Part6.5">6.1</a>, <a href="#rfc.xref.Part6.6">7.3</a>, <a href="#rfc.xref.Part6.7">7.4</a>, <a href="#rfc.xref.Part6.8">7.5</a>, <a href="#rfc.xref.Part6.9">7.6</a>, <a href="#rfc.xref.Part6.10">7.7</a>, <a href="#rfc.xref.Part6.11">8.2.1</a>, <a href="#rfc.xref.Part6.12">8.2.4</a>, <a href="#rfc.xref.Part6.13">8.2. 7</a>, <a href="#rfc.xref.Part6.14">8.3.1</a>, <a href="#rfc.xref.Part6.15">8.3.2</a>, <a href="#rfc.xref.Part6.16">8.4.11</a>, <a href="#Part6"><b>13.1</b></a><ul>3257 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">2.2.1</a>, <a href="#rfc.xref.Part6.2">4.2.1</a>, <a href="#rfc.xref.Part6.3">5</a>, <a href="#rfc.xref.Part6.4">5</a>, <a href="#rfc.xref.Part6.5">6.1</a>, <a href="#rfc.xref.Part6.6">7.3</a>, <a href="#rfc.xref.Part6.7">7.4</a>, <a href="#rfc.xref.Part6.8">7.5</a>, <a href="#rfc.xref.Part6.9">7.6</a>, <a href="#rfc.xref.Part6.10">7.7</a>, <a href="#rfc.xref.Part6.11">8.2.1</a>, <a href="#rfc.xref.Part6.12">8.2.4</a>, <a href="#rfc.xref.Part6.13">8.2.4</a>, <a href="#rfc.xref.Part6.14">8.2.4</a>, <a href="#rfc.xref.Part6.15">8.2.7</a>, <a href="#rfc.xref.Part6.16">8.3.1</a>, <a href="#rfc.xref.Part6.17">8.3.2</a>, <a href="#rfc.xref.Part6.18">8.4.11</a>, <a href="#Part6"><b>13.1</b></a><ul> 3253 3258 <li><em>Section 2.3.1</em> <a href="#rfc.xref.Part6.8">7.5</a></li> 3254 <li><em>Section 2.3.1.1</em> <a href="#rfc.xref.Part6.11">8.2.1</a>, <a href="#rfc.xref.Part6.1 2">8.2.4</a>, <a href="#rfc.xref.Part6.13">8.2.7</a>, <a href="#rfc.xref.Part6.14">8.3.1</a>, <a href="#rfc.xref.Part6.15">8.3.2</a>, <a href="#rfc.xref.Part6.16">8.4.11</a></li>3259 <li><em>Section 2.3.1.1</em> <a href="#rfc.xref.Part6.11">8.2.1</a>, <a href="#rfc.xref.Part6.14">8.2.4</a>, <a href="#rfc.xref.Part6.15">8.2.7</a>, <a href="#rfc.xref.Part6.16">8.3.1</a>, <a href="#rfc.xref.Part6.17">8.3.2</a>, <a href="#rfc.xref.Part6.18">8.4.11</a></li> 3255 3260 <li><em>Section 2.5</em> <a href="#rfc.xref.Part6.9">7.6</a>, <a href="#rfc.xref.Part6.10">7.7</a></li> 3256 3261 <li><em>Section 2.8</em> <a href="#rfc.xref.Part6.5">6.1</a></li> 3257 3262 <li><em>Section 3.1</em> <a href="#rfc.xref.Part6.3">5</a></li> 3263 <li><em>Section 3.2</em> <a href="#rfc.xref.Part6.12">8.2.4</a></li> 3258 3264 <li><em>Section 3.5</em> <a href="#rfc.xref.Part6.4">5</a></li> 3265 <li><em>Section 3.6</em> <a href="#rfc.xref.Part6.13">8.2.4</a></li> 3259 3266 </ul> 3260 3267 </li> … … 3325 3332 <li>201 Created <a href="#rfc.xref.status.201.1">4.1</a>, <a href="#rfc.iref.s.5"><b>8.2.2</b></a>, <a href="#rfc.xref.status.201.2">10.2</a></li> 3326 3333 <li>202 Accepted <a href="#rfc.xref.status.202.1">4.1</a>, <a href="#rfc.iref.s.6"><b>8.2.3</b></a>, <a href="#rfc.xref.status.202.2">10.2</a></li> 3327 <li>203 Non-Authoritative Information <a href="#rfc.xref.status.203.1">4.1</a>, <a href="#rfc.iref.s.7"><b>8.2.4</b></a>, <a href="#rfc.xref.status.203.2">10.2</a> </li>3334 <li>203 Non-Authoritative Information <a href="#rfc.xref.status.203.1">4.1</a>, <a href="#rfc.iref.s.7"><b>8.2.4</b></a>, <a href="#rfc.xref.status.203.2">10.2</a>, <a href="#rfc.xref.status.203.3">A</a></li> 3328 3335 <li>204 No Content <a href="#rfc.xref.status.204.1">4.1</a>, <a href="#rfc.iref.s.8"><b>8.2.5</b></a>, <a href="#rfc.xref.status.204.2">10.2</a></li> 3329 3336 <li>205 Reset Content <a href="#rfc.xref.status.205.1">4.1</a>, <a href="#rfc.iref.s.9"><b>8.2.6</b></a>, <a href="#rfc.xref.status.205.2">10.2</a></li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1303 r1309 29 29 <!ENTITY uri "<xref target='Part1' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 30 30 <!ENTITY effective-request-uri "<xref target='Part1' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 31 <!ENTITY intermediaries "<xref target='Part1' x:rel='#intermediaries' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 31 32 <!ENTITY full-date "<xref target='Part1' x:rel='#date.time.formats.full.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 32 33 <!ENTITY http-url "<xref target='Part1' x:rel='#http-url' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 1403 1404 <iref primary="true" item="Status Codes" subitem="203 Non-Authoritative Information" x:for-anchor=""/> 1404 1405 <t> 1405 The returned metadata in the header fields is not the 1406 definitive set as available from the origin server, but is gathered 1407 from a local or a third-party copy. The set presented &MAY; be a subset 1408 or superset of the original version. For example, including local 1409 annotation information about the resource might result in a superset 1410 of the metadata known by the origin server. Use of this 1411 response code is not required and is only appropriate when the 1412 response would otherwise be 200 (OK). 1406 The representation in the response has been transformed or otherwise 1407 modified by a transforming proxy (&intermediaries;). Note that the 1408 behaviour of transforming intermediaries is controlled by the no-transform 1409 Cache-Control directive (&header-cache-control;). 1410 </t> 1411 <t> 1412 This status code is only appropriate when the response status code would 1413 have been 200 (OK) otherwise. When the status code before transformation 1414 would have been different, the 214 Transformation Applied warn-code 1415 (&header-warning;) is appropriate. 1413 1416 </t> 1414 1417 <t> … … 1416 1419 freshness for 203 responses. 1417 1420 </t> 1418 1419 1421 </section> 1420 1422 … … 3511 3513 </t> 3512 3514 <t> 3515 Broadened the definition of 203 (Non-Authoritative Information) to include 3516 cases of payload transformations as well. 3517 (<xref target="status.203"/>) 3518 </t> 3519 <t> 3513 3520 Failed to consider that there are 3514 3521 many other request methods that are safe to automatically redirect, … … 4129 4136 "clarify 403 forbidden" 4130 4137 </t> 4138 <t> 4139 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/296"/>: 4140 "Clarify 203 Non-Authoritative Information" 4141 </t> 4131 4142 </list> 4132 4143 </t>
Note: See TracChangeset
for help on using the changeset viewer.