RE: Push and Caching

On our client side, we do have the (optional) concept of a navigation as a group of requests from the client, if the caller chooses to inform us of that grouping.  Internally, we treat push as a pre-response, not a cache insertion -- if the client never actually makes the corresponding request during the navigation, we won't cache it even if it's cacheable; if the response isn't cacheable, we'll still deliver it to the client if it's requested as part of the same navigation.  Any pushed content that's unretrieved when the navigation concludes gets discarded.

Mark's change makes part of that behavior invalid, and we need to nail down what the spec-compliant behavior is.

You're right that a proxy probably isn't going to have that information, just as we don't from all callers.  It could possibly scope that to requests from the same client in a certain period of time, use the Referrer header, or other heuristics to know when a request is "related" to the one that the push happened on.

-----Original Message-----
From: William Chow [mailto:wchow@mobolize.com] 
Sent: Thursday, August 21, 2014 2:27 PM
To: Mark Nottingham; Martin Thomson
Cc: Mike Bishop; HTTP Working Group
Subject: RE: Push and Caching

The discussion on "matching hint responses to requests" imply that pushed/prefetched responses need "navigation context" or a "document wide cache" to avoid having an HTTP2 layer unnecessarily revalidate just-pushed responses. While this might be possible for a browser/UA (although it implies coordination b/t the HTML and HTTP layers in that UA), this seems impractical for a proxy.  IOW, a proxy would only have limited context (e.g. Referer?) to avoid unnecessarily revalidating just-pushed responses. So, am I understanding that correctly, or have I missed something? 

--Will

-----Original Message-----
From: Mark Nottingham [mailto:mnot@mnot.net]
Sent: Tuesday, August 19, 2014 7:50 PM
To: Martin Thomson
Cc: Mike Bishop; HTTP Working Group
Subject: Re: Push and Caching

So, in that change I was just trying to be clear about what "cacheable" meant; note that in the original text, it linked to *response* cacheability in RFC7234, not request.

Mike, for your use case, CC: no-cache *is* cacheable; it just needs to be revalidated before reuse. See <http://httpwg.github.io/specs/rfc7234.html#response.cacheability> and <http://httpwg.github.io/specs/rfc7234.html#cache-response-directive>

Things get a bit nasty here because we don't define the scope of validity for a newly-pushed response, but we could nail that down with a bit of work, I think.

If we want to be able to push *truly* uncacheable responses (e.g., CC: no-store), we could say that a) cacheable pushed responses SHOULD be stored by caches, whereas uncacheable pushed responses MAY be consumed by the receiving application or discarded. This makes me a bit nervous, as HTTP/2 isn't chartered to create new HTTP semantics, and that's sailing awfully close to the wind...

Regardless, we need to be a bit more careful with words there, since response cacheability is partially determined by whether the cache is shared, and the server generating the response can't know the nature of downstream caches. 

I'll try to come up with an improvement in a pull request.

BTW, this all ties up really closely with what the application does *after* the HTTP cache in browsers; this is all only roughly specified at the moment, see:
  https://github.com/igrigorik/resource-hints/issues/5
  https://www.w3.org/Bugs/Public/show_bug.cgi?id=26350

Cheers,



On 20 Aug 2014, at 3:25 am, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 19 August 2014 08:21, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
>> I missed when that change happened.  Can someone with better git-fu 
>> remind me?  Was there list discussion?
> 
> https://github.com/http2/http2-spec/commit/3cec55e8
> 
> The change title: untangle relationship between pushing, promising, 
> and caching
> 
> -          A server can only push responses that are cacheable (see
> <xref target="HTTP-p6" x:fmt=","
> -          x:rel="#response.cacheability"/>); promised requests MUST
> be safe (see <xref
> -          target="HTTP-p2" x:fmt="," x:rel="#safe.methods"/>) and
> MUST NOT include a request body.
> +          A server can only push requests that are safe (see <xref
> target="HTTP-p2" x:fmt=","^M
> +          x:rel="#safe.methods"/>), cacheable (see <xref
> target="HTTP-p6" x:fmt=","^M
> +          x:rel="#response.cacheability"/>) and do not include a
> request body.^M
> 
> This was part of what was intended to be an editorial fix, along with 
> a large bunch of other edits
> (https://github.com/http2/http2-spec/commits/master?page=18) and I 
> missed the subtle, but substantive change in the midst of the rest.
> 
> I think that the `Cache-Control: nocache` response is a useful 
> feature.  I do remember being careful to permit uncacheable responses, 
> knowing that this would be an important use case.  I want to be able 
> to use push to trivially replace long-polling and this would help with 
> that.
> 
> Maybe Mark can defend his change.

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

Received on Thursday, 21 August 2014 21:47:34 UTC