- From: Mark Nottingham <mnot@mnot.net>
- Date: Sat, 3 Mar 2012 11:13:25 +1100
- To: Henrik Nordström <henrik@henriknordstrom.net>
- Cc: ietf-http-wg@w3.org
OK, I'm going to incorporate for -19 (with the correction). On 02/03/2012, at 11:04 PM, Henrik Nordström wrote: > Looks good to me, if correcting the copy-paste 304 reference. > > fre 2012-03-02 klockan 17:19 +1100 skrev Mark Nottingham: >> On 16/02/2012, at 6:25 PM, Henrik Nordström wrote: >> >>> mån 2012-02-13 klockan 15:45 +1100 skrev Mark Nottingham: >>>> New: >>>> >>>> The response to a HEAD request is cacheable; it MAY be used to satisfy >>>> subsequent HEAD requests. >>> >>> You just lost the property of HEAD updating GET responses. This is a >>> very intentional property. >>> >>> HEAD response == GET response minus body. As such it has the same cache >>> metadata update properties as 304 responses or merge of 204 responses. >> >> >> Proposal: >> >> >> Index: p2-semantics.xml >> =================================================================== >> --- p2-semantics.xml (revision 1553) >> +++ p2-semantics.xml (working copy) >> @@ -85,6 +85,7 @@ >> <!ENTITY p6-heuristic "<xref target='Part6' x:rel='#heuristic.freshness' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> >> <!ENTITY p6-explicit "<xref target='Part6' x:rel='#calculating.freshness.lifetime' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> >> <!ENTITY p6-invalid "<xref target='Part6' x:rel='#invalidation.after.updates.or.deletions' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> >> + <!ENTITY p6-head "<xref target='Part6' x:rel='#head.effects' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> >> ]> >> <?rfc toc="yes" ?> >> <?rfc symrefs="yes" ?> >> @@ -1035,12 +1036,8 @@ >> </t> >> <t> >> The response to a HEAD request is cacheable and &MAY; be used to satisfy >> - a subsequent HEAD request; see &caching;. It also &MAY; be used to update a previously cached >> - representation from that resource; if the new field values >> - indicate that the cached representation differs from the current representation (as >> - would be indicated by a change in Content-Length, ETag >> - or Last-Modified), then the cache &MUST; treat the cache entry as >> - stale. >> + a subsequent HEAD request. It also has potential side effects on >> + previously stored responses to GET; see &p6-head;. >> </t> >> <t> >> Bodies on HEAD requests have no defined semantics. Note that sending a body >> >> >> >> Index: p6-cache.xml >> =================================================================== >> --- p6-cache.xml (revision 1553) >> +++ p6-cache.xml (working copy) >> @@ -1013,7 +1013,7 @@ >> </list> >> </t> >> >> -<section anchor="freshening.responses" title="Freshening Responses"> >> +<section anchor="freshening.responses" title="Freshening Responses with 304 Not Modified"> >> <t> >> When a cache receives a 304 (Not Modified) response and already has one >> or more stored 200 (OK) responses for the same cache key, the cache needs >> @@ -1055,8 +1055,40 @@ >> </t> >> </section> >> >> +<section anchor="head.effects" title="Updating Caches with HEAD Responses"> >> +<t> >> + A response to the HEAD method is identical to what an equivalent request >> + made with a GET would have been, except it lacks a body. This property >> + of HEAD responses is used to both invalidate and update cached GET >> + responses. >> +</t> >> +<t> >> + If one or more stored GET responses can be selected (as per <xref >> + target="caching.negotiated.responses"/>) for a HEAD request, and the >> + Content-Length, ETag or Last-Modified value of a HEAD response differs from >> + that in a selected GET response, the cache &MUST; consider that selected >> + response to be stale. >> +</t> >> +<t> >> + If the Content-Length, ETag and Last-Modified values of a HEAD response >> + (when present) are the same as that in a selected GET response (as per >> + <xref target="caching.negotiated.responses"/>), the cache SHOULD update the >> + remaining headers in the stored response using the following rules: >> + <list style="symbols"> >> + <t>delete any Warning header fields in the stored response with >> + warn-code 1xx (see <xref target="header.warning" />);</t> >> + <t>retain any Warning header fields in the stored response with >> + warn-code 2xx; and,</t> >> + <t>use other header fields provided in the 304 response to replace >> + all instances of the corresponding header fields in the stored >> + response.</t> >> + </list> >> +</t> >> + >> </section> >> >> +</section> >> + >> <section anchor="invalidation.after.updates.or.deletions" >> title="Request Methods that Invalidate"> >> <t> >> >> >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> >> > > -- Mark Nottingham http://www.mnot.net/
Received on Saturday, 3 March 2012 00:13:53 UTC