Changeset 691 for draft-ietf-httpbis


Ignore:
Timestamp:
Sep 11, 2009, 2:58:13 AM (10 years ago)
Author:
julian.reschke@…
Message:

remove requirement to consider Content-Location in successful responses in order to determine the appropriate response to use (see #167)

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

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p6-cache.html

    r689 r691  
    398398      <meta name="DC.Creator" content="Reschke, J. F.">
    399399      <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    400       <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-01">
     400      <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-11">
    401401      <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616">
    402402      <meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document is Part 6 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
     
    430430         </tr>
    431431         <tr>
    432             <td class="header left">Expires: March 5, 2010</td>
     432            <td class="header left">Expires: March 15, 2010</td>
    433433            <td class="header right">HP</td>
    434434         </tr>
     
    487487         <tr>
    488488            <td class="header left"></td>
    489             <td class="header right">September 1, 2009</td>
     489            <td class="header right">September 11, 2009</td>
    490490         </tr>
    491491      </table>
     
    511511      <p>The list of Internet-Draft Shadow Directories can be accessed at &lt;<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>&gt;.
    512512      </p>
    513       <p>This Internet-Draft will expire in March 5, 2010.</p>
     513      <p>This Internet-Draft will expire in March 15, 2010.</p>
    514514      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    515515      <p>Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    902902      <p id="rfc.section.2.4.p.6">If a cache receives a 5xx response while attempting to validate a response, it <em class="bcp14">MAY</em> either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it <em class="bcp14">MAY</em> return a previously stored response (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;2.3.3</a>).
    903903      </p>
    904       <p id="rfc.section.2.4.p.7">If a cache receives a successful response whose Content-Location field matches that of an existing stored response for the
    905          same Request-URI, whose entity-tag differs from that of the existing stored response, and whose Date is more recent than that
    906          of the existing response, the existing response <em class="bcp14">SHOULD NOT</em> be returned in response to future requests and <em class="bcp14">SHOULD</em> be deleted from the cache. <span class="comment" id="rfc.comment.6">[<a href="#rfc.comment.6" class="smpl">rfc.comment.6</a>: DISCUSS: Not sure if this is necessary.]</span>
    907       </p>
    908904      <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a>&nbsp;<a id="invalidation.after.updates.or.deletions" href="#invalidation.after.updates.or.deletions">Request Methods that Invalidate</a></h2>
    909905      <p id="rfc.section.2.5.p.1">Because unsafe methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) have the potential for changing state on the origin server, intervening caches can use them to keep their contents up-to-date.
     
    919915         attacks.
    920916      </p>
    921       <p id="rfc.section.2.5.p.4"> <span class="comment" id="rfc.comment.7">[<a href="#rfc.comment.7" class="smpl">rfc.comment.7</a>: TODO: "host part" needs to be specified better.]</span>
     917      <p id="rfc.section.2.5.p.4"> <span class="comment" id="rfc.comment.6">[<a href="#rfc.comment.6" class="smpl">rfc.comment.6</a>: TODO: "host part" needs to be specified better.]</span>
    922918      </p>
    923919      <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 Request-URI.
     
    929925         change at the origin server might not have gone through the cache where a response is stored.
    930926      </p>
    931       <p id="rfc.section.2.5.p.8"> <span class="comment" id="rfc.comment.8">[<a href="#rfc.comment.8" class="smpl">rfc.comment.8</a>: TODO: specify that only successful (2xx, 3xx?) responses invalidate.]</span>
     927      <p id="rfc.section.2.5.p.8"> <span class="comment" id="rfc.comment.7">[<a href="#rfc.comment.7" class="smpl">rfc.comment.7</a>: TODO: specify that only successful (2xx, 3xx?) responses invalidate.]</span>
    932928      </p>
    933929      <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a>&nbsp;<a id="caching.negotiated.responses" href="#caching.negotiated.responses">Caching Negotiated Responses</a></h2>
     
    936932      </p>
    937933      <p id="rfc.section.2.6.p.2">The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first
    938          request can be transformed to the selecting request-headers in the second request by adding or removing linear white space <span class="comment" id="rfc.comment.9">[<a href="#rfc.comment.9" class="smpl">rfc.comment.9</a>: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field
     934         request can be transformed to the selecting request-headers in the second request by adding or removing linear white space <span class="comment" id="rfc.comment.8">[<a href="#rfc.comment.8" class="smpl">rfc.comment.8</a>: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field
    939935         name following the rules about header fields in <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
    940936      </p>
     
    951947         be used to satisfy the request.
    952948      </p>
    953       <p id="rfc.section.2.7.p.2">If the new response contains an ETag, it identifies the stored response to use. <span class="comment" id="rfc.comment.10">[<a href="#rfc.comment.10" class="smpl">rfc.comment.10</a>: may need language about Content-Location here]</span><span class="comment" id="rfc.comment.11">[<a href="#rfc.comment.11" class="smpl">rfc.comment.11</a>: cover case where INM with multiple etags was sent]</span>
     949      <p id="rfc.section.2.7.p.2">If the new response contains an ETag, it identifies the stored response to use. <span class="comment" id="rfc.comment.9">[<a href="#rfc.comment.9" class="smpl">rfc.comment.9</a>: may need language about Content-Location here]</span><span class="comment" id="rfc.comment.10">[<a href="#rfc.comment.10" class="smpl">rfc.comment.10</a>: cover case where INM with multiple etags was sent]</span>
    954950      </p>
    955951      <p id="rfc.section.2.7.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.
     
    966962      <p id="rfc.section.2.7.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.
    967963      </p>
    968       <p id="rfc.section.2.7.p.6">The updated response can [[<span class="comment" id="rfc.comment.12">[<a href="#rfc.comment.12" class="smpl">rfc.comment.12</a>: requirement?]</span>]] be used to replace the stored response in cache. In the case of a 206 response, the combined entity-body <em class="bcp14">MAY</em> be stored.
    969       </p>
    970       <p id="rfc.section.2.7.p.7"> <span class="comment" id="rfc.comment.13">[<a href="#rfc.comment.13" class="smpl">rfc.comment.13</a>: ISSUE: discuss how to handle HEAD updates]</span>
     964      <p id="rfc.section.2.7.p.6">The updated response can [[<span class="comment" id="rfc.comment.11">[<a href="#rfc.comment.11" class="smpl">rfc.comment.11</a>: requirement?]</span>]] be used to replace the stored response in cache. In the case of a 206 response, the combined entity-body <em class="bcp14">MAY</em> be stored.
     965      </p>
     966      <p id="rfc.section.2.7.p.7"> <span class="comment" id="rfc.comment.12">[<a href="#rfc.comment.12" class="smpl">rfc.comment.12</a>: ISSUE: discuss how to handle HEAD updates]</span>
    971967      </p>
    972968      <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>
     
    10541050            time. If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its expiration time
    10551051            by no more than the specified number of seconds. If no value is assigned to max-stale, then the client is willing to accept
    1056             a stale response of any age. <span class="comment" id="rfc.comment.14">[<a href="#rfc.comment.14" class="smpl">rfc.comment.14</a>: of any staleness? --mnot]</span></dd>
     1052            a stale response of any age. <span class="comment" id="rfc.comment.13">[<a href="#rfc.comment.13" class="smpl">rfc.comment.13</a>: of any staleness? --mnot]</span></dd>
    10571053      </dl>
    10581054      <p id="rfc.section.3.2.1.p.6"> <span id="rfc.iref.c.8"></span>  <span id="rfc.iref.m.3"></span> min-fresh
     
    15371533      <p id="rfc.section.A.1.p.2">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow
    15381534         for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are
    1539          computed. (see also <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> and <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) <span class="comment" id="rfc.comment.15">[<a href="#rfc.comment.15" class="smpl">rfc.comment.15</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span>
    1540       </p>
    1541       <p id="rfc.section.A.1.p.3">Proxies should be able to add Content-Length when appropriate. <span class="comment" id="rfc.comment.16">[<a href="#rfc.comment.16" class="smpl">rfc.comment.16</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span>
     1535         computed. (see also <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> and <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) <span class="comment" id="rfc.comment.14">[<a href="#rfc.comment.14" class="smpl">rfc.comment.14</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span>
     1536      </p>
     1537      <p id="rfc.section.A.1.p.3">Proxies should be able to add Content-Length when appropriate. <span class="comment" id="rfc.comment.15">[<a href="#rfc.comment.15" class="smpl">rfc.comment.15</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span>
    15421538      </p>
    15431539      <p id="rfc.section.A.1.p.4">Range request responses would become very verbose if all meta-data were always returned; by allowing the server to only send
     
    15491545      </p>
    15501546      <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2>
    1551       <p id="rfc.section.A.2.p.1">Clarify denial of service attack avoidance requirement. (<a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section&nbsp;2.5</a>)
    1552       </p>
    1553       <p id="rfc.section.A.2.p.2">Do not mention RFC 2047 encoding and multiple languages in Warning headers anymore, as these aspects never were implemented.
     1547      <p id="rfc.section.A.2.p.1">Remove requirement to consider Content-Location in successful responses in order to determine the appropriate response to
     1548         use. (<a href="#validation.model" title="Validation Model">Section&nbsp;2.4</a>)
     1549      </p>
     1550      <p id="rfc.section.A.2.p.2">Clarify denial of service attack avoidance requirement. (<a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section&nbsp;2.5</a>)
     1551      </p>
     1552      <p id="rfc.section.A.2.p.3">Do not mention RFC 2047 encoding and multiple languages in Warning headers anymore, as these aspects never were implemented.
    15541553         (<a href="#header.warning" id="rfc.xref.header.warning.5" title="Warning">Section&nbsp;3.6</a>)
    15551554      </p>
     
    17211720      <p id="rfc.section.C.9.p.1">Closed issues: </p>
    17221721      <ul>
     1722         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/167">http://tools.ietf.org/wg/httpbis/trac/ticket/167</a>&gt;: "Content-Location on 304 responses"
     1723         </li>
    17231724         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/187">http://tools.ietf.org/wg/httpbis/trac/ticket/187</a>&gt;: "RFC2047 and warn-text"
    17241725         </li>
  • draft-ietf-httpbis/latest/p6-cache.xml

    r689 r691  
    756756  target="serving.stale.responses" />).
    757757</t>
    758 <t>
    759   If a cache receives a successful response whose Content-Location field 
    760   matches that of an existing stored response for the same Request-URI, 
    761   whose entity-tag differs from that of the existing stored response, 
    762   and whose Date is more recent than that of the existing response, the 
    763   existing response &SHOULD-NOT; be returned in response to future 
    764   requests and &SHOULD; be deleted from the cache. <cref>DISCUSS: Not 
    765   sure if this is necessary.</cref>
    766 </t>
    767758</section>
    768759
     
    20702061<section anchor="changes.from.rfc.2616" title="Changes from RFC 2616">
    20712062<t>
     2063  Remove requirement to consider Content-Location in successful responses
     2064  in order to determine the appropriate response to use.
     2065  (<xref target="validation.model" />)
     2066</t>
     2067<t>
    20722068  Clarify denial of service attack avoidance requirement.
    20732069  (<xref target="invalidation.after.updates.or.deletions" />)
     
    23092305  <list style="symbols">
    23102306    <t>
     2307      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/167"/>:
     2308      "Content-Location on 304 responses"
     2309    </t>
     2310    <t>
    23112311      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/187"/>:
    23122312      "RFC2047 and warn-text"
Note: See TracChangeset for help on using the changeset viewer.