Ignore:
Timestamp:
09/06/13 08:02:35 (7 years ago)
Author:
fielding@…
Message:

Mention 203 (Non-Authoritative Information) in description of payload transformations; addresses #465

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

Legend:

Unmodified
Added
Removed

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

    r2286 r2287  
    449449  }
    450450  @bottom-center {
    451        content: "Expires December 10, 2013";
     451       content: "Expires December 11, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    491491      <meta name="dct.creator" content="Reschke, J. F.">
    492492      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    493       <meta name="dct.issued" scheme="ISO8601" content="2013-06-08">
     493      <meta name="dct.issued" scheme="ISO8601" content="2013-06-09">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    495495      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    … …  
    520520            <tr>
    521521               <td class="left">Intended status: Standards Track</td>
    522                <td class="right">June 8, 2013</td>
     522               <td class="right">June 9, 2013</td>
    523523            </tr>
    524524            <tr>
    525                <td class="left">Expires: December 10, 2013</td>
     525               <td class="left">Expires: December 11, 2013</td>
    526526               <td class="right"></td>
    527527            </tr>
    … …  
    551551         in progress”.
    552552      </p>
    553       <p>This Internet-Draft will expire on December 10, 2013.</p>
     553      <p>This Internet-Draft will expire on December 11, 2013.</p>
    554554      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    555555      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    19401940      </p>
    19411941      <p id="rfc.section.5.7.2.p.6">A transforming proxy <em class="bcp14">MAY</em> transform the payload of a message that does not contain the no-transform cache-control directive; if the payload is transformed,
    1942          the transforming proxy <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) header field if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 7.5</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
     1942         the transforming proxy <em class="bcp14">MUST</em> add a Warning header field with the warn-code of 214 ("Transformation Applied") if one does not already appear in the message
     1943         (see <a href="p6-cache.html#header.warning" title="Warning">Section 7.5</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). If the payload of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response is transformed, the transforming proxy can also inform downstream recipients that a transformation has been applied
     1944         by changing the response status code to <a href="p2-semantics.html#status.203" class="smpl">203 (Non-Authoritative Information)</a> (<a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 6.3.4</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    19431945      </p>
    19441946      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="connection.management" href="#connection.management">Connection Management</a></h1>
    … …  
    20342036      </p>
    20352037      <p id="rfc.section.6.3.1.p.2">When an inbound connection is closed prematurely, a client <em class="bcp14">MAY</em> open a new connection and automatically retransmit an aborted sequence of requests if all of those requests have idempotent
    2036          methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). A proxy <em class="bcp14">MUST NOT</em> automatically retry non-idempotent requests.
     2038         methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). A proxy <em class="bcp14">MUST NOT</em> automatically retry non-idempotent requests.
    20372039      </p>
    20382040      <p id="rfc.section.6.3.1.p.3">A user agent <em class="bcp14">MUST NOT</em> automatically retry a request with a non-idempotent method unless it has some means to know that the request semantics are
    … …  
    20462048      </p>
    20472049      <h3 id="rfc.section.6.3.2"><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;<a id="pipelining" href="#pipelining">Pipelining</a></h3>
    2048       <p id="rfc.section.6.3.2.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "<dfn>pipeline</dfn>" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MAY</em> process a sequence of pipelined requests in parallel if they all have safe methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), but <em class="bcp14">MUST</em> send the corresponding responses in the same order that the requests were received.
     2050      <p id="rfc.section.6.3.2.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "<dfn>pipeline</dfn>" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MAY</em> process a sequence of pipelined requests in parallel if they all have safe methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), but <em class="bcp14">MUST</em> send the corresponding responses in the same order that the requests were received.
    20492051      </p>
    20502052      <p id="rfc.section.6.3.2.p.2">A client that pipelines requests <em class="bcp14">MUST</em> be prepared to retry those requests if the connection closes before it receives all of the corresponding responses. A client
    20512053         that assumes a persistent connection and pipelines immediately after connection establishment <em class="bcp14">MUST NOT</em> pipeline on a retry connection until it knows the connection is persistent.
    20522054      </p>
    2053       <p id="rfc.section.6.3.2.p.3">Idempotent methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) are significant to pipelining because they can be automatically retried after a connection failure. A user agent <em class="bcp14">SHOULD NOT</em> pipeline requests after a non-idempotent method until the final response status code for that method has been received, unless
     2055      <p id="rfc.section.6.3.2.p.3">Idempotent methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) are significant to pipelining because they can be automatically retried after a connection failure. A user agent <em class="bcp14">SHOULD NOT</em> pipeline requests after a non-idempotent method until the final response status code for that method has been received, unless
    20542056         the user agent has a means to detect and recover from partial failure conditions involving the pipelined sequence.
    20552057      </p>
    … …  
    21652167      <p id="rfc.section.6.7.p.11">The Upgrade header field only applies to switching protocols on top of the existing connection; it cannot be used to switch
    21662168         the underlying connection (transport) protocol, nor to switch the existing communication to a different connection. For those
    2167          purposes, it is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 6.4</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     2169         purposes, it is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 6.4</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    21682170      </p>
    21692171      <p id="rfc.section.6.7.p.12">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined
    … …  
    24322434         <li>Pointer to specification text</li>
    24332435      </ul>
    2434       <p id="rfc.section.7.4.1.p.2">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) unless the encoding transformation is identical, as is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;4.2</a>.
     2436      <p id="rfc.section.7.4.1.p.2">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) unless the encoding transformation is identical, as is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;4.2</a>.
    24352437      </p>
    24362438      <p id="rfc.section.7.4.1.p.3">Values to be added to this name space require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this specification.
    … …  
    25702572         that most implementations will choose substantially higher limits.
    25712573      </p>
    2572       <p id="rfc.section.8.3.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 6.5</a> of <a href="#Part2" id="rfc.xref.Part2.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Additional status codes related to capacity limits have been defined by extensions to HTTP <a href="#RFC6585" id="rfc.xref.RFC6585.1"><cite title="Additional HTTP Status Codes">[RFC6585]</cite></a>.
     2574      <p id="rfc.section.8.3.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 6.5</a> of <a href="#Part2" id="rfc.xref.Part2.30"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Additional status codes related to capacity limits have been defined by extensions to HTTP <a href="#RFC6585" id="rfc.xref.RFC6585.1"><cite title="Additional HTTP Status Codes">[RFC6585]</cite></a>.
    25732575      </p>
    25742576      <p id="rfc.section.8.3.p.4">Recipients <em class="bcp14">SHOULD</em> carefully limit the extent to which they read other fields, including (but not limited to) request methods, response status
    … …  
    34003402            </li>
    34013403            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    3402                   <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2.1</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.14">3.3.2</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.17">4.3</a>, <a href="#rfc.xref.Part2.18">5.1</a>, <a href="#rfc.xref.Part2.19">5.3</a>, <a href="#rfc.xref.Part2.20">5.3</a>, <a href="#rfc.xref.Part2.21">5.6</a>, <a href="#rfc.xref.Part2.22">5.7.2</a>, <a href="#rfc.xref.Part2.23">6.3.1</a>, <a href="#rfc.xref.Part2.24">6.3.2</a>, <a href="#rfc.xref.Part2.25">6.3.2</a>, <a href="#rfc.xref.Part2.26">6.7</a>, <a href="#rfc.xref.Part2.27">7.4.1</a>, <a href="#rfc.xref.Part2.28">8.3</a>, <a href="#rfc.xref.Part2.29">8.3</a>, <a href="#Part2"><b>10.1</b></a><ul>
     3404                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2.1</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.14">3.3.2</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.17">4.3</a>, <a href="#rfc.xref.Part2.18">5.1</a>, <a href="#rfc.xref.Part2.19">5.3</a>, <a href="#rfc.xref.Part2.20">5.3</a>, <a href="#rfc.xref.Part2.21">5.6</a>, <a href="#rfc.xref.Part2.22">5.7.2</a>, <a href="#rfc.xref.Part2.23">5.7.2</a>, <a href="#rfc.xref.Part2.24">6.3.1</a>, <a href="#rfc.xref.Part2.25">6.3.2</a>, <a href="#rfc.xref.Part2.26">6.3.2</a>, <a href="#rfc.xref.Part2.27">6.7</a>, <a href="#rfc.xref.Part2.28">7.4.1</a>, <a href="#rfc.xref.Part2.29">8.3</a>, <a href="#rfc.xref.Part2.30">8.3</a>, <a href="#Part2"><b>10.1</b></a><ul>
    34033405                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">2.7</a></li>
    34043406                        <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">3.3.2</a></li>
    3405                         <li><em>Section 3.1.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.27">7.4.1</a></li>
     3407                        <li><em>Section 3.1.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.28">7.4.1</a></li>
    34063408                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.22">5.7.2</a></li>
    34073409                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">3.1.1</a></li>
    3408                         <li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.24">6.3.2</a></li>
    3409                         <li><em>Section 4.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.23">6.3.1</a>, <a href="#rfc.xref.Part2.25">6.3.2</a></li>
     3410                        <li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.25">6.3.2</a></li>
     3411                        <li><em>Section 4.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.24">6.3.1</a>, <a href="#rfc.xref.Part2.26">6.3.2</a></li>
    34103412                        <li><em>Section 4.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.15">3.3.2</a></li>
    34113413                        <li><em>Section 4.3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.19">5.3</a></li>
    … …  
    34143416                        <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a></li>
    34153417                        <li><em>Section 6.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.21">5.6</a></li>
    3416                         <li><em>Section 6.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.3</a></li>
    3417                         <li><em>Section 6.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.26">6.7</a></li>
    3418                         <li><em>Section 6.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.29">8.3</a></li>
    3419                         <li><em>Section 6.5.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.28">8.3</a></li>
     3418                        <li><em>Section 6.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.23">5.7.2</a></li>
     3419                        <li><em>Section 6.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.27">6.7</a></li>
     3420                        <li><em>Section 6.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.30">8.3</a></li>
     3421                        <li><em>Section 6.5.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.29">8.3</a></li>
    34203422                        <li><em>Section 7.1.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">3.2</a></li>
    34213423                        <li><em>Section 8.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">3.2.1</a></li>

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

    r2286 r2287  
    26992699   that does not contain the no-transform cache-control directive;
    27002700   if the payload is transformed, the transforming proxy &MUST; add a
    2701    Warning 214 (Transformation applied) header field if one does not
    2702    already appear in the message (see &header-warning;).
     2701   Warning header field with the warn-code of 214 ("Transformation Applied")
     2702   if one does not already appear in the message (see &header-warning;).
     2703   If the payload of a <x:ref>200 (OK)</x:ref> response is transformed, the
     2704   transforming proxy can also inform downstream recipients that a
     2705   transformation has been applied by changing the response status code to
     2706   <x:ref>203 (Non-Authoritative Information)</x:ref> (&status-203;).
    27032707</t>
    27042708</section>
    … …  
    40614065    <x:defines>2xx</x:defines>
    40624066    <x:defines>200 (OK)</x:defines>
     4067    <x:defines>203 (Non-Authoritative Information)</x:defines>
    40634068    <x:defines>204 (No Content)</x:defines>
    40644069    <x:defines>3xx (Redirection)</x:defines>
Note: See TracChangeset for help on using the changeset viewer.