Re: Push and Caching

another +1.. we definitely want to be able to use a non-cacheable push
response one time if it isn't going into a general cache layer.


On Thu, Aug 21, 2014 at 5:47 PM, Mike Bishop <Michael.Bishop@microsoft.com>
wrote:

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