W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: #227: HEAD and Caches

From: Mark Nottingham <mnot@mnot.net>
Date: Sat, 3 Mar 2012 11:13:25 +1100
Cc: ietf-http-wg@w3.org
Message-Id: <C36BBA4A-24BB-4A42-8DF8-A7EFC5A772EE@mnot.net>
To: Henrik Nordström <henrik@henriknordstrom.net>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:56 GMT