RE: Push and Caching

[William Chow <[e-mail]>]

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:[e-mail]] 
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 <[e-mail]> wrote:

> On 19 August 2014 08:21, Mike Bishop <[e-mail]> 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/