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

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 24 Jul 2009 02:03:42 +0200

Comments to the comments in p6 2.7

2.7 Combining Responses

        If the new response contains an ETag, it identifies the stored
        response to use. [rfc.comment.10: may need language about
        Content-Location here][rfc.comment.11: cover case where INM with
        multiple etags was sent] 

10: Yes, with an almost identical sentence following

        If the new response does not contains an ETag but contains an
        Content-Location, it identifies the stored response to use.

covering the case where there is no ETag but Content-Location.

11: Don't see what needs to covered there. What's important is the ETag
found in the response, not which etag-values we sent in I-N-M. There
will only be at most one ETag in the response.

Regards
Henrik

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 24 Jul 2009 13:03:20 +1000

>  covering the case where there is no ETag but Content-Location.

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?

> will only be at most one ETag in the response.

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...

Cheers,

--
Mark Nottingham     http://www.mnot.net/

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 24 Jul 2009 06:57:36 +0200

> 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

> 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