* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Changeset 691


Ignore:
Timestamp:
2009-09-11 02:58:13 (5 years ago)
Author:
julian.reschke@gmx.de
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.