Changeset 939 for draft-ietf-httpbis
- Timestamp:
- 24/07/10 15:27:25 (12 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 4 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/extract-header-defs.xslt
r291 r939 79 79 <c><xsl:value-of select="iref[@item='Headers']/@subitem"/></c> 80 80 <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> 87 82 <c><xref target="{@anchor}"/></c> 88 83 </xsl:template> -
draft-ietf-httpbis/latest/p1-messaging.html
r923 r939 859 859 <a href="#abnf.dependencies" class="smpl">response-header</a> = <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>> 860 860 </pre><div id="rfc.figure.u.13"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">entity-header</a> = <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>> 861 <a href="#abnf.dependencies" class="smpl">MIME-Version</a> = <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>> 861 862 </pre><div id="rfc.figure.u.14"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">Cache-Control</a> = <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>> 862 863 <a href="#abnf.dependencies" class="smpl">Pragma</a> = <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>> … … 1301 1302 / <a href="#header.via" class="smpl">Via</a> ; <a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 9.9</a> 1302 1303 / <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> 1303 1305 </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 1304 1306 or experimental header fields might be given the semantics of general header fields if all parties in the communication recognize … … 1312 1314 *(( <a href="#general.header.fields" class="smpl">general-header</a> ; <a href="#general.header.fields" title="General Header Fields">Section 3.4</a> 1313 1315 / <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> 1315 1317 <a href="#core.rules" class="smpl">CRLF</a> 1316 1318 [ <a href="#message.body" class="smpl">message-body</a> ] ; <a href="#message.body" title="Message Body">Section 3.3</a> … … 1442 1444 *(( <a href="#general.header.fields" class="smpl">general-header</a> ; <a href="#general.header.fields" title="General Header Fields">Section 3.4</a> 1443 1445 / <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> 1445 1447 <a href="#core.rules" class="smpl">CRLF</a> 1446 1448 [ <a href="#message.body" class="smpl">message-body</a> ] ; <a href="#message.body" title="Message Body">Section 3.3</a> … … 1690 1692 <li>Pointer to specification text</li> 1691 1693 </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 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 6.2.2</a>). 1693 1695 </p> 1694 1696 <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" … … 1710 1712 </p> 1711 1713 <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a> <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 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 weight1714 <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 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 1713 1715 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 1714 1716 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. … … 1842 1844 </p> 1843 1845 </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 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 6.2</a>). 1845 1847 </p> 1846 1848 <h3 id="rfc.section.7.1.4"><a href="#rfc.section.7.1.4">7.1.4</a> <a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3> … … 2170 2172 <h2 id="rfc.section.9.7"><a href="#rfc.section.9.7">9.7</a> <a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h2> 2171 2173 <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-codings2174 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 2173 2175 are not. 2174 2176 </p> … … 2862 2864 </p> 2863 2865 <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>. 2865 2867 </p> 2866 2868 <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> … … 2995 2997 <a href="#header.host" class="smpl">Host-v</a> = uri-host [ ":" port ] 2996 2998 2999 <a href="#abnf.dependencies" class="smpl">MIME-Version</a> = <MIME-Version, defined in [Part3], Appendix A.1> 2997 3000 <a href="#method" class="smpl">Method</a> = token 2998 3001 … … 3075 3078 3076 3079 <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 3078 3081 3079 3082 <a href="#header.fields" class="smpl">header-field</a> = field-name ":" OWS [ field-value ] OWS … … 3411 3414 </li> 3412 3415 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/83">http://tools.ietf.org/wg/httpbis/trac/ticket/83</a>>: "OPTIONS * and proxies" 3416 </li> 3417 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/122">http://tools.ietf.org/wg/httpbis/trac/ticket/122</a>>: "MIME-Version not listed in P1, general header fields" 3413 3418 </li> 3414 3419 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/143">http://tools.ietf.org/wg/httpbis/trac/ticket/143</a>>: "IANA registry for content/transfer encodings" … … 3672 3677 </ul> 3673 3678 </li> 3674 <li class="indline1"><em>Part3</em> <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> <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> <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> <a class="iref" href="#rfc.xref.Part3. 6">6.4</a></li>3679 <li class="indline1"><em>Part3</em> <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> <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> <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> <a class="iref" href="#rfc.xref.Part3.8">6.4</a></li> 3678 3683 <li class="indline1"><em>Appendix A</em> <a class="iref" href="#rfc.xref.Part3.1">1</a></li> 3684 <li class="indline1"><em>Appendix A.1</em> <a class="iref" href="#rfc.xref.Part3.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.4">3.4</a></li> 3679 3685 </ul> 3680 3686 </li> -
draft-ietf-httpbis/latest/p3-payload.html
r923 r939 1395 1395 <td class="left">Content-Disposition</td> 1396 1396 <td class="left">http</td> 1397 <td class="left"> </td>1397 <td class="left">standard</td> 1398 1398 <td class="left"> <a href="#content-disposition" id="rfc.xref.content-disposition.1" title="Content-Disposition">Appendix B.1</a> 1399 1399 </td> … … 1437 1437 <td class="left">MIME-Version</td> 1438 1438 <td class="left">http</td> 1439 <td class="left"> </td>1439 <td class="left">standard</td> 1440 1440 <td class="left"> <a href="#mime-version" id="rfc.xref.mime-version.1" title="MIME-Version">Appendix A.1</a> 1441 1441 </td> … … 2046 2046 <p id="rfc.section.E.11.p.1">Closed issues: </p> 2047 2047 <ul> 2048 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/122">http://tools.ietf.org/wg/httpbis/trac/ticket/122</a>>: "MIME-Version not listed in P1, general header fields" 2049 </li> 2048 2050 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/143">http://tools.ietf.org/wg/httpbis/trac/ticket/143</a>>: "IANA registry for content/transfer encodings" 2049 2051 </li> -
draft-ietf-httpbis/latest/p6-cache.html
r931 r939 780 780 </li> 781 781 </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 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 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 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 2.3.2</a>. 783 783 </p> 784 784 <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 … … 948 948 <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. 949 949 </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 955 953 mark these as "invalid" and in need of a mandatory validation before they can be returned in response to a subsequent request. 956 954 </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 the955 <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 958 956 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>961 957 </p> 962 958 <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a> <a id="caching.authenticated.responses" href="#caching.authenticated.responses">Shared Caching of Authenticated Responses</a></h2> … … 996 992 <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"), 997 993 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. 1003 999 </p> 1004 1000 <p id="rfc.section.2.8.p.4">The stored response headers are used as those of the updated response, except that </p> 1005 1001 <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 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 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. 1016 1011 </p> 1017 1012 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> … … 1101 1096 time. If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its expiration time 1102 1097 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> 1104 1100 </ul> 1105 1101 <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> … … 1907 1903 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/223">http://tools.ietf.org/wg/httpbis/trac/ticket/223</a>>: "Allowing heuristic caching for new status codes" 1908 1904 </li> 1905 <li>Clean up TODOs and prose in "Combining Responses."</li> 1909 1906 </ul> 1910 1907 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
Note: See TracChangeset
for help on using the changeset viewer.