Re: p6 2.7, suggested resolutions to comments 10 & 11.

fre 2009-07-24 klockan 13:03 +1000 skrev Mark Nottingham:

> Perhaps, pending resolution of <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/167 
>  >. You indicated there that you thought this use of Content-Location  
> should be removed; have you changed your mind?

Yes. It's not that bad to do response selection based on
Content-Location. Sure the first requests unil you have learnt the
mapping isn't as efficient as when there is an ETag but then it equals
out.

But I still don't think it has seen any widespread deployment yet, if
even implemented by anyone (yet).

If I had understood Content-Location better when writing the
content-negotiation support in Squid it probably would have suppored
Content-Location today however

> Right, but the case where an INM was sent and there isn't an ETag in  
> the response -- or the ETag doesn't match a stored one -- needs to be  
> covered. This is actually a much larger issue...

This is 2.7, combining of two responses of the same variant.

For 304 ETag mismatch is covered in p4 3.1, and also p6 2.4.

For 206 it's the next sentence here in p6 2.7, in addition to p6 2.4.

For the purpose of combining two responses it does not matter what INM
there was in the request. All that matters is the "identity" of the seen
responses. 

This "identity" is defined by ETag, Content-Location if no ETag and
selecting request headers if neither ETag or Content-Location and with
Last-Modified as validator.

The cache only needs the URI + responses + selecting request headers as
indicated by Vary to do it's little logic dance in figuring out what to
merge if possible.

1. Is there an ETag? Then that's it. May be a good idea to verify
Last-Modified as well if present but not required (only needed to detect
borked servers).

2. If no ETag but there is Content-Location? Then that's it. Together
with Last-Modified as validator (p4 3.1, p6 2.4). Those also covers when
the new response suddenly have no ETag but the stored do..

None of this needs to remember what we actually put in the INM request.
The request could for that matter have used If-Modified-Since: 01 Jan
1970 00:00:00 GMT, of If-Range: <lmt-date>  and the cache would still do
the right thing even if perhaps not very optimal.. (a bit too many
retries in p4 3.1 on negotiated resources, but nothing excessive).


Regards
Henrik

Received on Friday, 24 July 2009 04:58:22 UTC