Ignore:
Timestamp:
Jun 21, 2011, 11:49:40 PM (8 years ago)
Author:
julian.reschke@…
Message:

Clarify 203 Non-Authoritative Information (see #296)"

Location:
draft-ietf-httpbis/latest
Files:
4 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.html

    r1306 r1309  
    359359  }
    360360  @bottom-center {
    361        content: "Expires December 10, 2011";
     361       content: "Expires December 24, 2011";
    362362  }
    363363  @bottom-right {
    … …  
    410410      <meta name="dct.creator" content="Reschke, J. F.">
    411411      <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">
    413413      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    414414      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    … …  
    442442            </tr>
    443443            <tr>
    444                <td class="left">Expires: December 10, 2011</td>
     444               <td class="left">Expires: December 24, 2011</td>
    445445               <td class="right">HP</td>
    446446            </tr>
    … …  
    495495            <tr>
    496496               <td class="left"></td>
    497                <td class="right">June 8, 2011</td>
     497               <td class="right">June 22, 2011</td>
    498498            </tr>
    499499         </tbody>
    … …  
    525525         in progress”.
    526526      </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>
    528528      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    529529      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    967967         or an intranet-to-Internet privacy filter. Such transformations are presumed to be desired by the client (or client organization)
    968968         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.
    970970      </p>
    971971      <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
    … …  
    10061006</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
    10071007         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>.
    10091009      </p>
    10101010      <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
    … …  
    11441144      <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> ]
    11451145</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>).
    11471147      </p>
    11481148      <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
    … …  
    13511351      <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
    13521352         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>.
    13541354      </p>
    13551355      <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
    … …  
    14371437      <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.
    14381438      </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>).
    14401440      </p>
    14411441      <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,
    … …  
    14701470      </div>
    14711471      <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>).
    14731473      </p>
    14741474      <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.
    … …  
    15511551</pre><h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;<a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h3>
    15521552      <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,
    15541554         out of deference to earlier Internet application protocols that were more frequently used with interactive text clients. A
    15551555         client <em class="bcp14">SHOULD</em> ignore the content of the Reason Phrase.
    … …  
    18741874      <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.
    18751875      </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 to
     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.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
    18771877         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.
    18781878      </p>
    … …  
    19371937         <li>Content-Type</li>
    19381938      </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>).
    19401940      </p>
    19411941      <div class="note" id="rfc.section.7.1.3.2.p.7">
    … …  
    19601960      </p>
    19611961      <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 understanding
     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.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
    19631963         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.
    19641964      </p>
    … …  
    19871987      </p>
    19881988      <h3 id="rfc.section.7.2.3"><a href="#rfc.section.7.2.3">7.2.3</a>&nbsp;<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 willing
     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.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
    19901990         to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might
    19911991         either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without
    … …  
    19941994      <p id="rfc.section.7.2.3.p.2">Requirements for HTTP/1.1 clients: </p>
    19951995      <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.
    19991999         </li>
    20002000      </ul>
    … …  
    20402040         <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
    20412041            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>).
    20432043         </li>
    20442044      </ul>
    … …  
    21042104      </p>
    21052105      <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>).
    21072107      </p>
    21082108      <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
    … …  
    23162316      </p>
    23172317      <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.10"><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>).
    23192319      </p>
    23202320      <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
    … …  
    38003800            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    38013801                  <li><em>Pad1995</em>&nbsp;&nbsp;<a href="#rfc.xref.Pad1995.1">7.1.1</a>, <a href="#Pad1995"><b>13.2</b></a></li>
    3802                   <li><em>Part2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">4.1.2</a></li>
    3805                         <li><em>Section 8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">5.1.1</a></li>
    3806                         <li><em>Section 8.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">7.2.3</a></li>
    3807                         <li><em>Section 8.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">7.2.3</a></li>
    3808                         <li><em>Section 8.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">9.8</a></li>
    3809                         <li><em>Section 8.4.15</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">4.1.2</a></li>
    3810                         <li><em>Section 9.2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">4.1.2</a></li>
     3805                        <li><em>Section 8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">5.1.1</a></li>
     3806                        <li><em>Section 8.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">7.2.3</a></li>
     3807                        <li><em>Section 8.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">7.2.3</a></li>
     3808                        <li><em>Section 8.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.3</a></li>
     3809                        <li><em>Section 8.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">9.8</a></li>
     3810                        <li><em>Section 8.4.15</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">4.1.2</a></li>
     3811                        <li><em>Section 9.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.8">7.2.3</a>, <a href="#rfc.xref.Part2.9">7.2.3</a></li>
    38113812                     </ul>
    38123813                  </li>
    … …  
    38173818                     </ul>
    38183819                  </li>
    3819                   <li><em>Part6</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.4</a></li>
    3821                         <li><em>Section 2.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">3.3</a></li>
    3822                         <li><em>Section 3.2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">7.1.3.2</a></li>
     3820                  <li><em>Part6</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part6.2">2.4</a></li>
     3822                        <li><em>Section 2.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">3.3</a></li>
     3823                        <li><em>Section 3.2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.3</a>, <a href="#rfc.xref.Part6.5">7.1.3.2</a></li>
    38243825                     </ul>
    38253826                  </li>

  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1306 r1309  
    3434  <!ENTITY status-100             "<xref target='Part2' x:rel='#status.100' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3535  <!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'/>">
    3637  <!ENTITY status-3xx             "<xref target='Part2' x:rel='#status.3xx' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3738  <!ENTITY status-414             "<xref target='Part2' x:rel='#status.414' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    710711   this specification.  However, when a proxy is not intended to transform
    711712   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.
    713715</t>
    714716<t><iref primary="true" item="gateway"/><iref primary="true" item="reverse proxy"/>

  • draft-ietf-httpbis/latest/p2-semantics.html

    r1303 r1309  
    359359  }
    360360  @bottom-center {
    361        content: "Expires December 3, 2011";
     361       content: "Expires December 24, 2011";
    362362  }
    363363  @bottom-right {
    … …  
    409409      <meta name="dct.creator" content="Reschke, J. F.">
    410410      <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">
    412412      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    413413      <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 &#34;HTTP/1.1&#34; 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.">
    … …  
    440440            </tr>
    441441            <tr>
    442                <td class="left">Expires: December 3, 2011</td>
     442               <td class="left">Expires: December 24, 2011</td>
    443443               <td class="right">HP</td>
    444444            </tr>
    … …  
    493493            <tr>
    494494               <td class="left"></td>
    495                <td class="right">June 1, 2011</td>
     495               <td class="right">June 22, 2011</td>
    496496            </tr>
    497497         </tbody>
    … …  
    522522         in progress”.
    523523      </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>
    525525      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    526526      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    16011601      <div id="rfc.iref.s.7"></div>
    16021602      <h3 id="rfc.section.8.2.4"><a href="#rfc.section.8.2.4">8.2.4</a>&nbsp;<a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3>
    1603       <p id="rfc.section.8.2.4.p.1">The returned metadata in the header fields is not the definitive set as available from the origin server, but is gathered
    1604          from a local or a third-party copy. The set presented <em class="bcp14">MAY</em> be a subset or superset of the original version. For example, including local annotation information about the resource might
    1605          result in a superset of the metadata known by the origin server. Use of this response code is not required and is only appropriate
    1606          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.
    16091609      </p>
    16101610      <div id="rfc.iref.28"></div>
    … …  
    16361636         another input action.
    16371637      </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.27"><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>.
    16391639      </p>
    16401640      <div id="rfc.iref.30"></div>
    … …  
    16441644         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>.
    16451645      </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.13"><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.
    16471647      </p>
    16481648      <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a>&nbsp;<a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2>
    … …  
    16681668      <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.
    16691669      </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.14"><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.
    16711671      </p>
    16721672      <div id="rfc.iref.32"></div>
    … …  
    16761676         request URI to one or more of the new references returned by the server, where possible.
    16771677      </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.15"><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.
    16791679      </p>
    16801680      <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).
    … …  
    18501850         — that is left to the discretion of the server owner.
    18511851      </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.16"><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.
    18531853      </p>
    18541854      <div id="rfc.iref.50"></div>
    … …  
    19011901      <div id="rfc.iref.s.37"></div>
    19021902      <h3 id="rfc.section.8.4.19"><a href="#rfc.section.8.4.19">8.4.19</a>&nbsp;<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.28"><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.
    19041904      </p>
    19051905      <div id="rfc.figure.u.7"></div>
    … …  
    19581958      <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
    19591959         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.
    19611961      </p>
    19621962      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
    … …  
    19981998      </p>
    19991999      <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.30"><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.
    20012001      </p>
    20022002      <div id="rfc.iref.f.1"></div>
    … …  
    21022102      <h2 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a>&nbsp;<a id="header.server" href="#header.server">Server</a></h2>
    21032103      <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.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for
     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.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
    21052105         identifying the application.
    21062106      </p>
    … …  
    21082108</pre><p id="rfc.section.9.8.p.4">Example:</p>
    21092109      <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.33"><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>).
    21112111      </p>
    21122112      <div class="note" id="rfc.section.9.8.p.7">
    … …  
    21242124         user agent limitations.
    21252125      </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.34"><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 significance
     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.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
    21272127         for identifying the application.
    21282128      </p>
    … …  
    27112711      <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&nbsp;7.9</a>)
    27122712      </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&nbsp;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
    27142716         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>)
    27152717      </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 resource
     2718      <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
    27172719         must be accessed through the proxy given by the Location field. The Location field gave the URI of the proxy. The recipient
    27182720         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&nbsp;8.3.6</a>)
    27192721      </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&nbsp;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&nbsp;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 requirement
     2722      <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&nbsp;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&nbsp;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
    27252727         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&nbsp;9.1</a>)
    27262728      </p>
    2727       <p id="rfc.section.A.p.10">Correct syntax of Location header field to allow URI references (including relative references and fragments), as referred
     2729      <p id="rfc.section.A.p.11">Correct syntax of Location header field to allow URI references (including relative references and fragments), as referred
    27282730         symbol "absoluteURI" wasn't what was expected, and add some clarifications as to when use of fragments would not be appropriate.
    27292731         (<a href="#header.location" id="rfc.xref.header.location.4" title="Location">Section&nbsp;9.4</a>)
    27302732      </p>
    2731       <p id="rfc.section.A.p.11">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&nbsp;9.5</a>)
    2732       </p>
    2733       <p id="rfc.section.A.p.12">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&nbsp;9.6</a>)
    2734       </p>
    2735       <p id="rfc.section.A.p.13">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated
    2736          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.36"><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&nbsp;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&nbsp;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&nbsp;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&nbsp;9.8</a>)
    27372739      </p>
    27382740      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    … …  
    30483050         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/294">http://tools.ietf.org/wg/httpbis/trac/ticket/294</a>&gt;: "clarify 403 forbidden"
    30493051         </li>
     3052         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/296">http://tools.ietf.org/wg/httpbis/trac/ticket/296</a>&gt;: "Clarify 203 Non-Authoritative Information"
     3053         </li>
    30503054      </ul>
    30513055      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
    … …  
    30633067                  <li>201 Created (status code)&nbsp;&nbsp;<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>
    30643068                  <li>202 Accepted (status code)&nbsp;&nbsp;<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)&nbsp;&nbsp;<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)&nbsp;&nbsp;<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>
    30663070                  <li>204 No Content (status code)&nbsp;&nbsp;<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>
    30673071                  <li>205 Reset Content (status code)&nbsp;&nbsp;<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>
    … …  
    32023206            </li>
    32033207            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    3204                   <li><em>Part1</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>
    32053209                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.2</a></li>
    32063210                        <li><em>Section 1.2.2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part1.29">8.5.6</a></li>
     3211                        <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.27">8.2.4</a></li>
     3212                        <li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.30">8.5.6</a></li>
    32083213                        <li><em>Section 2.6</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part1.10">1.2.2</a>, <a href="#rfc.xref.Part1.32">9.8</a>, <a href="#rfc.xref.Part1.35">9.9</a></li>
    3210                         <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.20">6</a>, <a href="#rfc.xref.Part1.27">8.2.6</a></li>
     3214                        <li><em>Section 3.2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>
    32113216                        <li><em>Section 4.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.24">7.9</a></li>
    32123217                        <li><em>Section 4.3</em>&nbsp;&nbsp;<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>
    32133218                        <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.11">1.2.2</a></li>
    3214                         <li><em>Section 6.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.31">9.8</a>, <a href="#rfc.xref.Part1.34">9.9</a></li>
    3215                         <li><em>Section 7.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.25">8.1.1</a>, <a href="#rfc.xref.Part1.30">9.2</a></li>
     3219                        <li><em>Section 6.3</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part1.25">8.1.1</a>, <a href="#rfc.xref.Part1.31">9.2</a></li>
    32163221                        <li><em>Section 9.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.17">3</a></li>
    32173222                        <li><em>Section 9.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.18">3</a></li>
    3218                         <li><em>Section 9.8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.26">8.1.2</a>, <a href="#rfc.xref.Part1.28">8.4.19</a></li>
    3219                         <li><em>Section 9.9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.22">7.8</a>, <a href="#rfc.xref.Part1.33">9.8</a>, <a href="#rfc.xref.Part1.36">A</a></li>
     3223                        <li><em>Section 9.8</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>
    32203225                        <li><em>Section 10.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.23">7.8</a></li>
    32213226                     </ul>
    … …  
    32503255                     </ul>
    32513256                  </li>
    3252                   <li><em>Part6</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>
    32533258                        <li><em>Section 2.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.8">7.5</a></li>
    3254                         <li><em>Section 2.3.1.1</em>&nbsp;&nbsp;<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></li>
     3259                        <li><em>Section 2.3.1.1</em>&nbsp;&nbsp;<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>
    32553260                        <li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.9">7.6</a>, <a href="#rfc.xref.Part6.10">7.7</a></li>
    32563261                        <li><em>Section 2.8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.5">6.1</a></li>
    32573262                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">5</a></li>
     3263                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.12">8.2.4</a></li>
    32583264                        <li><em>Section 3.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">5</a></li>
     3265                        <li><em>Section 3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.13">8.2.4</a></li>
    32593266                     </ul>
    32603267                  </li>
    … …  
    33253332                        <li>201 Created&nbsp;&nbsp;<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>
    33263333                        <li>202 Accepted&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    33283335                        <li>204 No Content&nbsp;&nbsp;<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>
    33293336                        <li>205 Reset Content&nbsp;&nbsp;<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  
    2929  <!ENTITY uri                        "<xref target='Part1' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3030  <!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'/>">
    3132  <!ENTITY full-date                  "<xref target='Part1' x:rel='#date.time.formats.full.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3233  <!ENTITY http-url                   "<xref target='Part1' x:rel='#http-url' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    14031404  <iref primary="true" item="Status Codes" subitem="203 Non-Authoritative Information" x:for-anchor=""/>
    14041405<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.
    14131416</t>
    14141417<t>
    … …  
    14161419   freshness for 203 responses.
    14171420</t>
    1418 
    14191421</section>
    14201422
    … …  
    35113513</t>
    35123514<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>
    35133520  Failed to consider that there are
    35143521  many other request methods that are safe to automatically redirect,
    … …  
    41294136      "clarify 403 forbidden"
    41304137    </t>
     4138    <t>
     4139      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/296"/>:
     4140      "Clarify 203 Non-Authoritative Information"
     4141    </t>
    41314142  </list>
    41324143</t>
Note: See TracChangeset for help on using the changeset viewer.