Changeset 939 for draft-ietf-httpbis


Ignore:
Timestamp:
24/07/10 15:27:25 (11 years ago)
Author:
julian.reschke@…
Message:

regen HTML

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

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/extract-header-defs.xslt

    r291 r939  
    7979  <c><xsl:value-of select="iref[@item='Headers']/@subitem"/></c>
    8080  <c>http</c>
    81   <c>
    82     <xsl:choose>
    83       <xsl:when test="ancestor::middle">standard</xsl:when>
    84       <xsl:otherwise></xsl:otherwise>
    85     </xsl:choose>
    86   </c>
     81  <c>standard</c>
    8782  <c><xref target="{@anchor}"/></c>
    8883</xsl:template>

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

    r923 r939  
    859859  <a href="#abnf.dependencies" class="smpl">response-header</a> = &lt;response-header, defined in <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 5</a>&gt;
    860860</pre><div id="rfc.figure.u.13"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">entity-header</a>   = &lt;entity-header, defined in <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a>&gt;
     861  <a href="#abnf.dependencies" class="smpl">MIME-Version</a>    = &lt;MIME-Version, defined in <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#mime-version" title="MIME-Version">Appendix A.1</a>&gt;
    861862</pre><div id="rfc.figure.u.14"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">Cache-Control</a>   = &lt;Cache-Control, defined in <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 3.4</a>&gt;
    862863  <a href="#abnf.dependencies" class="smpl">Pragma</a>          = &lt;Pragma, defined in <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 3.4</a>&gt;
    … …  
    13011302                 / <a href="#header.via" class="smpl">Via</a>                      ; <a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;9.9</a>
    13021303                 / <a href="#abnf.dependencies" class="smpl">Warning</a>                  ; <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a>
     1304                 / <a href="#abnf.dependencies" class="smpl">MIME-Version</a>             ; <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#mime-version" title="MIME-Version">Appendix A.1</a>
    13031305</pre><p id="rfc.section.3.4.p.3">General-header field names can be extended reliably only in combination with a change in the protocol version. However, new
    13041306         or experimental header fields might be given the semantics of general header fields if all parties in the communication recognize
    … …  
    13121314                  *(( <a href="#general.header.fields" class="smpl">general-header</a>        ; <a href="#general.header.fields" title="General Header Fields">Section&nbsp;3.4</a>
    13131315                   / <a href="#abnf.dependencies" class="smpl">request-header</a>         ; <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 3</a>
    1314                    / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a> ) ; <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a>
     1316                   / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a> ) ; <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a>
    13151317                  <a href="#core.rules" class="smpl">CRLF</a>
    13161318                  [ <a href="#message.body" class="smpl">message-body</a> ]          ; <a href="#message.body" title="Message Body">Section&nbsp;3.3</a>
    … …  
    14421444                  *(( <a href="#general.header.fields" class="smpl">general-header</a>        ; <a href="#general.header.fields" title="General Header Fields">Section&nbsp;3.4</a>
    14431445                   / <a href="#abnf.dependencies" class="smpl">response-header</a>        ; <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 5</a>
    1444                    / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a> ) ; <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a>
     1446                   / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a> ) ; <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a>
    14451447                  <a href="#core.rules" class="smpl">CRLF</a>
    14461448                  [ <a href="#message.body" class="smpl">message-body</a> ]          ; <a href="#message.body" title="Message Body">Section&nbsp;3.3</a>
    … …  
    16901692         <li>Pointer to specification text</li>
    16911693      </ul>
    1692       <p id="rfc.section.6.2.3.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;6.2.2</a>).
     1694      <p id="rfc.section.6.2.3.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;6.2.2</a>).
    16931695      </p>
    16941696      <p id="rfc.section.6.2.3.p.4">Values to be added to this name space require expert review and a specification (see "Expert Review" and "Specification Required"
    … …  
    17101712      </p>
    17111713      <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<a id="quality.values" href="#quality.values">Quality Values</a></h2>
    1712       <p id="rfc.section.6.4.p.1">Both transfer codings (TE request header, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section&nbsp;9.5</a>) and content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight
     1714      <p id="rfc.section.6.4.p.1">Both transfer codings (TE request header, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section&nbsp;9.5</a>) and content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight
    17131715         is normalized to a real number in the range 0 through 1, where 0 is the minimum and 1 the maximum value. If a parameter has
    17141716         a quality value of 0, then content with this parameter is "not acceptable" for the client. HTTP/1.1 applications <em class="bcp14">MUST NOT</em> generate more than three digits after the decimal point. User configuration of these values <em class="bcp14">SHOULD</em> also be limited in this fashion.
    … …  
    18421844         </p>
    18431845      </div>
    1844       <p id="rfc.section.7.1.3.2.p.8">A transparent proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), though it <em class="bcp14">MAY</em> change the message-body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>).
     1846      <p id="rfc.section.7.1.3.2.p.8">A transparent proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), though it <em class="bcp14">MAY</em> change the message-body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>).
    18451847      </p>
    18461848      <h3 id="rfc.section.7.1.4"><a href="#rfc.section.7.1.4">7.1.4</a>&nbsp;<a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3>
    … …  
    21702172      <h2 id="rfc.section.9.7"><a href="#rfc.section.9.7">9.7</a>&nbsp;<a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h2>
    21712173      <p id="rfc.section.9.7.p.1">The "Transfer-Encoding" general-header field indicates what transfer-codings (if any) have been applied to the message body.
    2172          It differs from Content-Encoding (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) in that transfer-codings are a property of the message (and therefore are removed by intermediaries), whereas content-codings
     2174         It differs from Content-Encoding (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) in that transfer-codings are a property of the message (and therefore are removed by intermediaries), whereas content-codings
    21732175         are not.
    21742176      </p>
    … …  
    28622864      </p>
    28632865      <p id="rfc.section.A.p.4">The character set of a representation <em class="bcp14">SHOULD</em> be labeled as the lowest common denominator of the character codes used within that representation, with the exception that
    2864          not labeling the representation is preferred over labeling the representation with the labels US-ASCII or ISO-8859-1. See <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
     2866         not labeling the representation is preferred over labeling the representation with the labels US-ASCII or ISO-8859-1. See <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
    28652867      </p>
    28662868      <p id="rfc.section.A.p.5">Additional rules for requirements on parsing and encoding of dates and other potential problems with date encodings include:</p>
    … …  
    29952997<a href="#header.host" class="smpl">Host-v</a> = uri-host [ ":" port ]
    29962998
     2999<a href="#abnf.dependencies" class="smpl">MIME-Version</a> = &lt;MIME-Version, defined in [Part3], Appendix A.1&gt;
    29973000<a href="#method" class="smpl">Method</a> = token
    29983001
    … …  
    30753078
    30763079<a href="#general.header.fields" class="smpl">general-header</a> = Cache-Control / Connection / Date / Pragma / Trailer
    3077  / Transfer-Encoding / Upgrade / Via / Warning
     3080 / Transfer-Encoding / Upgrade / Via / Warning / MIME-Version
    30783081
    30793082<a href="#header.fields" class="smpl">header-field</a> = field-name ":" OWS [ field-value ] OWS
    … …  
    34113414         </li>
    34123415         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/83">http://tools.ietf.org/wg/httpbis/trac/ticket/83</a>&gt;: "OPTIONS * and proxies"
     3416         </li>
     3417         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/122">http://tools.ietf.org/wg/httpbis/trac/ticket/122</a>&gt;: "MIME-Version not listed in P1, general header fields"
    34133418         </li>
    34143419         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/143">http://tools.ietf.org/wg/httpbis/trac/ticket/143</a>&gt;: "IANA registry for content/transfer encodings"
    … …  
    36723677                     </ul>
    36733678                  </li>
    3674                   <li class="indline1"><em>Part3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1</a>, <a class="iref" href="#rfc.xref.Part3.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.3">4</a>, <a class="iref" href="#rfc.xref.Part3.4">5</a>, <a class="iref" href="#rfc.xref.Part3.5">6.2.3</a>, <a class="iref" href="#rfc.xref.Part3.6">6.4</a>, <a class="iref" href="#rfc.xref.Part3.7">7.1.3.2</a>, <a class="iref" href="#rfc.xref.Part3.8">9.7</a>, <a class="iref" href="#Part3"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part3.9">A</a><ul class="ind">
    3675                         <li class="indline1"><em>Section 2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.5">6.2.3</a>, <a class="iref" href="#rfc.xref.Part3.8">9.7</a></li>
    3676                         <li class="indline1"><em>Section 3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.3">4</a>, <a class="iref" href="#rfc.xref.Part3.4">5</a></li>
    3677                         <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.6">6.4</a></li>
     3679                  <li class="indline1"><em>Part3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1</a>, <a class="iref" href="#rfc.xref.Part3.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.4">3.4</a>, <a class="iref" href="#rfc.xref.Part3.5">4</a>, <a class="iref" href="#rfc.xref.Part3.6">5</a>, <a class="iref" href="#rfc.xref.Part3.7">6.2.3</a>, <a class="iref" href="#rfc.xref.Part3.8">6.4</a>, <a class="iref" href="#rfc.xref.Part3.9">7.1.3.2</a>, <a class="iref" href="#rfc.xref.Part3.10">9.7</a>, <a class="iref" href="#Part3"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part3.11">A</a><ul class="ind">
     3680                        <li class="indline1"><em>Section 2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.7">6.2.3</a>, <a class="iref" href="#rfc.xref.Part3.10">9.7</a></li>
     3681                        <li class="indline1"><em>Section 3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.5">4</a>, <a class="iref" href="#rfc.xref.Part3.6">5</a></li>
     3682                        <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.8">6.4</a></li>
    36783683                        <li class="indline1"><em>Appendix A</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1</a></li>
     3684                        <li class="indline1"><em>Appendix A.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.4">3.4</a></li>
    36793685                     </ul>
    36803686                  </li>

  • draft-ietf-httpbis/latest/p3-payload.html

    r923 r939  
    13951395                  <td class="left">Content-Disposition</td>
    13961396                  <td class="left">http</td>
    1397                   <td class="left"></td>
     1397                  <td class="left">standard</td>
    13981398                  <td class="left"> <a href="#content-disposition" id="rfc.xref.content-disposition.1" title="Content-Disposition">Appendix&nbsp;B.1</a>
    13991399                  </td>
    … …  
    14371437                  <td class="left">MIME-Version</td>
    14381438                  <td class="left">http</td>
    1439                   <td class="left"></td>
     1439                  <td class="left">standard</td>
    14401440                  <td class="left"> <a href="#mime-version" id="rfc.xref.mime-version.1" title="MIME-Version">Appendix&nbsp;A.1</a>
    14411441                  </td>
    … …  
    20462046      <p id="rfc.section.E.11.p.1">Closed issues: </p>
    20472047      <ul>
     2048         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/122">http://tools.ietf.org/wg/httpbis/trac/ticket/122</a>&gt;: "MIME-Version not listed in P1, general header fields"
     2049         </li>
    20482050         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/143">http://tools.ietf.org/wg/httpbis/trac/ticket/143</a>&gt;: "IANA registry for content/transfer encodings"
    20492051         </li>

  • draft-ietf-httpbis/latest/p6-cache.html

    r931 r939  
    780780         </li>
    781781      </ul>
    782       <p id="rfc.section.2.2.p.2">When a stored response is used to satisfy a request, caches <em class="bcp14">MUST</em> include a single Age header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;3.1</a>) in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>. <span class="comment" id="DISCUSS-includes-validated">[<a href="#DISCUSS-includes-validated" class="smpl">DISCUSS-includes-validated</a>: this currently includes successfully validated responses.]</span>
     782      <p id="rfc.section.2.2.p.2">When a stored response is used to satisfy a request without validation, caches <em class="bcp14">MUST</em> include a single Age header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;3.1</a>) in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>.
    783783      </p>
    784784      <p id="rfc.section.2.2.p.3">Requests with methods that are unsafe (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) <em class="bcp14">MUST</em> be written through the cache to the origin server; i.e., a cache must not reply to such a request before having forwarded
    … …  
    948948      <p id="rfc.section.2.5.p.3">An invalidation based on a URI from a Location or Content-Location header <em class="bcp14">MUST NOT</em> be performed if the host part of that URI differs from the host part in the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). This helps prevent denial of service attacks.
    949949      </p>
    950       <p id="rfc.section.2.5.p.4"> <span class="comment" id="TODO-def-host-part">[<a href="#TODO-def-host-part" class="smpl">TODO-def-host-part</a>: "host part" needs to be specified better.]</span>
    951       </p>
    952       <p id="rfc.section.2.5.p.5">A cache that passes through requests for methods it does not understand <em class="bcp14">SHOULD</em> invalidate the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    953       </p>
    954       <p id="rfc.section.2.5.p.6">Here, "invalidate" means that the cache will either remove all stored responses related to the Effective Request URI, or will
     950      <p id="rfc.section.2.5.p.4">A cache that passes through requests for methods it does not understand <em class="bcp14">SHOULD</em> invalidate the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     951      </p>
     952      <p id="rfc.section.2.5.p.5">Here, "invalidate" means that the cache will either remove all stored responses related to the Effective Request URI, or will
    955953         mark these as "invalid" and in need of a mandatory validation before they can be returned in response to a subsequent request.
    956954      </p>
    957       <p id="rfc.section.2.5.p.7">Note that this does not guarantee that all appropriate responses are invalidated. For example, the request that caused the
     955      <p id="rfc.section.2.5.p.6">Note that this does not guarantee that all appropriate responses are invalidated. For example, the request that caused the
    958956         change at the origin server might not have gone through the cache where a response is stored.
    959       </p>
    960       <p id="rfc.section.2.5.p.8"> <span class="comment" id="TODO-spec-success-invalidate">[<a href="#TODO-spec-success-invalidate" class="smpl">TODO-spec-success-invalidate</a>: specify that only successful (2xx, 3xx?) responses invalidate.]</span>
    961957      </p>
    962958      <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a>&nbsp;<a id="caching.authenticated.responses" href="#caching.authenticated.responses">Shared Caching of Authenticated Responses</a></h2>
    … …  
    996992      <p id="rfc.section.2.8.p.1">When a cache receives a 304 (Not Modified) response or a 206 (Partial Content) response (in this section, the "new" response"),
    997993         it needs to created an updated response by combining the stored response with the new one, so that the updated response can
    998          be used to satisfy the request.
    999       </p>
    1000       <p id="rfc.section.2.8.p.2">If the new response contains an ETag, it identifies the stored response to use. <span class="comment" id="TODO-mention-CL">[<a href="#TODO-mention-CL" class="smpl">TODO-mention-CL</a>: might need language about Content-Location here]</span>
    1001       </p>
    1002       <p id="rfc.section.2.8.p.3">If the status code is 206 (partial content), both the stored and new responses <em class="bcp14">MUST</em> have validators, and those validators <em class="bcp14">MUST</em> match using the strong comparison function (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). Otherwise, the responses <em class="bcp14">MUST NOT</em> be combined.
     994         be used to satisfy the request, and potentially update the cached response.
     995      </p>
     996      <p id="rfc.section.2.8.p.2">If the new response contains an ETag, it identifies the stored response to use. <span class="comment" id="TODO-mention-CL">[<a href="#TODO-mention-CL" class="smpl">TODO-mention-CL</a>: might need language about Content-Location here]</span><span class="comment" id="TODO-select-for-combine">[<a href="#TODO-select-for-combine" class="smpl">TODO-select-for-combine</a>: Shouldn't this be the selected response?]</span>
     997      </p>
     998      <p id="rfc.section.2.8.p.3">If the new response's status code is 206 (partial content), both the stored and new responses <em class="bcp14">MUST</em> have validators, and those validators <em class="bcp14">MUST</em> match using the strong comparison function (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). Otherwise, the responses <em class="bcp14">MUST NOT</em> be combined.
    1003999      </p>
    10041000      <p id="rfc.section.2.8.p.4">The stored response headers are used as those of the updated response, except that </p>
    10051001      <ul>
    1006          <li>any stored Warning headers with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section&nbsp;3.6</a>) <em class="bcp14">MUST</em> be deleted from the stored response and the updated response.
    1007          </li>
    1008          <li>any stored Warning headers with warn-code 2xx <em class="bcp14">MUST</em> be retained in the stored response and the updated response.
    1009          </li>
    1010          <li>any headers provided in the new response <em class="bcp14">MUST</em> replace the corresponding headers from the stored response.
    1011          </li>
    1012       </ul>
    1013       <p id="rfc.section.2.8.p.5">If a header field-name in the new response matches more than one header in the stored response, all such stored headers <em class="bcp14">MUST</em> be replaced.
    1014       </p>
    1015       <p id="rfc.section.2.8.p.6">The updated response can <span class="comment" id="TODO-is-req">[<a href="#TODO-is-req" class="smpl">TODO-is-req</a>: requirement?]</span> be used to replace the stored response in cache. In the case of a 206 response, the combined representation <em class="bcp14">MAY</em> be stored.
     1002         <li>any stored Warning headers with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section&nbsp;3.6</a>) <em class="bcp14">MUST</em> be deleted.
     1003         </li>
     1004         <li>any stored Warning headers with warn-code 2xx <em class="bcp14">MUST</em> be retained.
     1005         </li>
     1006         <li>any other headers provided in the new response <em class="bcp14">MUST</em> replace all instances of the corresponding headers from the stored response.
     1007         </li>
     1008      </ul>
     1009      <p id="rfc.section.2.8.p.5">The updated response headers <em class="bcp14">MUST</em> be used to replace those of the stored response in cache (unless the stored response is removed from cache). In the case of
     1010         a 206 response, the combined representation <em class="bcp14">MAY</em> be stored.
    10161011      </p>
    10171012      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
    … …  
    11011096            time. If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its expiration time
    11021097            by no more than the specified number of seconds. If no value is assigned to max-stale, then the client is willing to accept
    1103             a stale response of any age. <span class="comment" id="TODO-staleness">[<a href="#TODO-staleness" class="smpl">TODO-staleness</a>: of any staleness? --mnot]</span></li>
     1098            a stale response of any age.
     1099         </li>
    11041100      </ul>
    11051101      <p id="rfc.section.3.2.1.p.6"> <dfn>min-fresh</dfn>  <span id="rfc.iref.c.8"></span>  <span id="rfc.iref.m.3"></span> 
    … …  
    19071903         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/223">http://tools.ietf.org/wg/httpbis/trac/ticket/223</a>&gt;: "Allowing heuristic caching for new status codes"
    19081904         </li>
     1905         <li>Clean up TODOs and prose in "Combining Responses."</li>
    19091906      </ul>
    19101907      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
Note: See TracChangeset for help on using the changeset viewer.