Subject: Re: Queries re P6

From: Mark Nottingham <[email-masked]>
Date: Mon, 12 Nov 2012 12:40:44 +1100

Hi Adrien,

Sorry for the delay; responses below.

On 31/10/2012, at 12:12 PM, Adrien W. de Croy <[email-masked]> wrote:

> 
> Hi all. 
> 
> We're currently refactoring our cache module, and have run into a few areas where there seems to be inconsistency between RFC2616 and p6, and other places where there are possibly ambiguities in p6.
> 
> Firstly, if one is to compare RFC 2616 10.3.5 with P6 4.2.1
> 
> in RFC2616 10.3.5 we have 
> 
> "If a 304 response indicates an entity not currently cached, then the cache MUST disregard the response and repeat the request without the conditional."
> 
> in P6 4.2.1 
> 
> "If none of the stored responses contain the same strong validator, then this new response corresponds to a new selected representation and MUST NOT update the existing stored responses."
> 
> I don't see anywhere in p6 where it says the response must be disregarded completely and the request re-issued. Isn't this therefore a semantic change (which I understood was outside the scope of httpbis)?

Validation itself has been moved to p4; this section is just about the impact of validation upon caches. 

IIRC we removed the requirement to reissue the request because there are some scenarios where it doesn't make sense to do so; e.g., if the incoming request was conditional, and you forward that, a 304 response need not trigger a re-request, even though you don't have it in cache locally. Of course, you can choose to do so if you like, but HTTP shouldn't require it.

> I don't understand how "Not modified" can be compatible with "new selected response".

I agree; I think we can change that language (which is explanatory, and doing a bad job of it) to: "If none of the stored responses contain the same strong validator, then the response MUST NOT be used to update any stored responses."

> in 4.2.1, 
> 
> "If the new response does not include any form of validator, there
> is only one stored response, and that stored response also lacks a
> validator, then that stored response is selected."
> 
> Firstly, there should be an "and" in there... e.g. it should read 
> 
> "If the new response does not include any form of validator, and there
> is only one stored response which also lacks a validator, then that stored response is selected."
> 
> But how can a server logically reply with 304 without a validator? 
> 
> A server can only reply with 304 if the request was conditional. For a request to be conditional, there must be a validator supplied with the request. But in this case the stored response had no validator. So where did the validator come from?
> 
> Does this mean that it's compliant behaviour to make a conditional request with data that wasn't in the stored response? E.g. have a cache invent an If-Modified-Since based on something else (e.g. Date)? Presumably a cache can't invent an ETag where there was none. Also, 4.2 para 2 states the If-Modified-Since comes from Last-Modified and doesn't imply it can come from elsewhere.
> 
> My initial reaction is to consider a 304 without validator to be a server bug.

This text was introduced by Roy in <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1374/draft-ietf-httpbis/latest/p6-cache.xml#L1096>. Roy, what was your thinking here?

> also:
> 
> "use other header fields provided in the 304 (Not Modified) response to replace all instances of the corresponding header fields in the stored response."
> 
> Should there be some limit on the fields that may be updated? Does it make sense for instance to allow updating of Content-Type?

I fear that if we go down the route of specifying which headers to pay attention to, we'll never get out of the rat hole. Besides, people might want to use a 304 to correct the Content-Type...

> in 4.3 may I clarify meaning of
> 
> "If no selected response is available, the cache can forward the presented request to the origin server in a conditional request; see Section 4.2."
> 
> "in a conditional request" is possibly ambiguous. To me this means the cache is entitled to make the request conditional by adding If-Modified-Since or If-None-Match etc. The request may have already been conditional (e.g. UA cache). So the purpose of the cache checking validity of something that failed selection is valid? E.g. the server gets the final say but may still choose to serve the same content (e.g. same ETag) even though it didn't match selectors?

That was unintentional; IIRC we softened some of the language from 2616 here, but didn't intend that reading.

How about:

"If no selected response is available, the cache cannot satisfy the presented request. Note that it can be forwarded to the origin server in a conditional request; see Section 4.2."

E.g., the cache might include ETags it knows about in the INM to allow the server to select from one of them.

> in 4.2 may I suggest some wording changes.
> 
> Para 2 does not indicate that it's not valid to add If-Modified-Since unless there was a Last-Modified header in the stored response.
> 
> E.g. instead of 
> 
> "When sending such a conditional request, a cache adds an If-Modified-Since header field whose value is that of the Last-Modified header field from the selected (see Section 4.3) stored response, if available."
> 
> maybe it should read something like
> 
> "If the selected stored response contains a Last-Modified header, a cache SHOULD add an If-Modified-Since header field whose value is that of the Last-Modified header field from the selected stored response."
> 
> Likewise Para 3 and If-None-Match. E.g instead of 
> 
> "Additionally, a cache can add an If-None-Match header field whose value is that of the ETag header field(s) from all responses stored for the requested URI, if present...."
> 
> maybe
> 
> "Additionally if any stored response contains an ETag header field, a cache SHOULD add an If-None-Match header whose value(s) are the ETag header field(s) from all stored responses for the requested URI."

I don't object to doing this; does anyone else?

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

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Mon, 12 Nov 2012 23:17:57 +0000

Hi Mark

------ Original Message ------
From: "Mark Nottingham" <[email-masked]>
>IIRC we removed the requirement to reissue the request because there are some scenarios where it doesn't make sense to do so; e.g., if the incoming request was conditional, and you forward that, a 3…

We see occasionally scenarios where it appears from the cache POV that 
the server is returning a 304 which matches neither the client's 
conditional request or our own.  E.g. a returned ETag matches none of 
the client's If-None-Match list, nor the cache's.

Is the recommended fall-back in this case to ignore the ETag from the 
server, and check if the Last-Modified (if present) matches any known 
If-Modified-Since from the client or cache?

Because it can be quite difficult for a cache to re-issue the request 
(e.g. upstream filters are oblivious that it's a retry).  In this case 
we simply pass the problem back to the client.

>I agree; I think we can change that language (which is explanatory, and doing a bad job of it) to: "If none of the stored responses contain the same strong validator, then the response MUST NOT be u…
ok
>E.g., the cache might include ETags it knows about in the INM to allow the server to select from one of them.

OK, so the distinction is that the cache must effectively re-validate.  
My point of re-validating non-selected representations is clarified by 
your example, so basically the cache is free to check other 
(non-selectable) representations with the server.  I can imagine 
circumstances where a server responds with say Vary: *, yet still 
wishes to send back a 304 since the ETag presented by the client or 
cache indicates the client or cache copy is still actually the desired 
one. 
thanks

Adrien

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 15 Nov 2012 18:10:29 +1100

> I agree; I think we can change that language (which is explanatory, and doing a bad job of it) to: "If none of the stored responses contain the same strong validator, then the response MUST NOT be…

In -latest.

> This text was introduced by Roy in <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1374/draft-ietf-httpbis/latest/p6-cache.xml#L1096>. Roy, what was your thinking here?

Raised as <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/406>.

> E.g., the cache might include ETags it knows about in the INM to allow the server to select from one of them.

In -latest, with slight modifications.

> I don't object to doing this; does anyone else?

Looking at this again, I'm not sure what making them requirements really buys us here. I'd be OK with adding some prose that says that creating IMS from values other than the LM from the origin is problematic, if that would address your concern.

Cheers,

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Thu, 15 Nov 2012 11:48:48 +0000

Hi Mark

------ Original Message ------
>Looking at this again, I'm not sure what making them requirements really buys us here. I'd be OK with adding some prose that says that creating IMS from values other than the LM from the origin is p…
I'd tend to agree.  My main point was that it wasn't explicit that you 
can't insert If-Modified-Since if you don't have a stored Last-Modifed 
(e.g .could be construed to allow adding an empty If-Modified-Since and 
If-None-Match), and likewise that you can't insert If-None-Match if you 
have no Etags.

Cheers

Adrien