Subject: Push and Caching

From: Mike Bishop <[email-masked]>
Date: Tue, 19 Aug 2014 15:21:34 +0000

Something we remarked on internally a while ago, but I keep forgetting to raise with the WG....  We had a discussion with Martin a long time ago about caching and push - specifically, that you can push a response to a cacheable request, regardless of whether the *response* is cacheable.

Martin said (off-list):
You'll note that the text does not prohibit what you describe there :)

The text says that the request needs to be cacheable.  It also says that the method needs to be cacheable.  It says nothing about the response.

Pushing a response with Cache-Control: nocache is perfectly OK.

However, the spec does now prohibit exactly that, in 8.2:
A server can only push responses that are cacheable (see [RFC7234]<http://http2.github.io/http2-spec/#RFC7234>, Section 3<https://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7234.html#response.cacheability>); promised requests MUST be safe (see [RFC7231]<http://http2.github.io/http2-spec/#RFC7231>, Section 4.2.1<https://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7231.html#safe.methods>) and MUST NOT include a request body.

I missed when that change happened.  Can someone with better git-fu remind me?  Was there list discussion?

---

From: Martin Thomson <[email-masked]>
Date: Tue, 19 Aug 2014 10:25:20 -0700

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

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 20 Aug 2014 09:20:08 +1000

On 20 August 2014 03:25, Martin Thomson <[email-masked]> wrote:

> knowing that this would be an important use case.
>

+1

With jetty SPDY we were only pushing static resources, but I  think that
static content is often moved off to CDNs anyway, so it is pushing any
dynamically generated associated resources that will be needed to reduce
the RTTs.

With jetty http2 we have re factored so that we can push dynamic resources
including ones that may be transient and marked no-cache. We are working
with application APIs so that details like what session/query
string/parameters to use for the push can be sorted out with knowledge from
the application framework.    Thus a pushed response to a GET /index.html
may include highly customised/personalised data and be different for every
push.

Off topic somewhat:

I want to be able
> to use push to trivially replace long-polling and this would help with

I can see that as being very useful for non-browser clients.      It would
be great if it could also be done in browser... but is there any suggestion
that a js API will be made available so that javascript frameworks can be
notified of the arrival of pushed resources?

cheers

-- 
Greg Wilkins <[email-masked]>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 19 Aug 2014 16:31:29 -0700

> notified of the arrival of pushed resources?

I've had some discussions about this in relation to the new
ServiceWorker API, which seems to be a good fit.  Nothing concrete
yet.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 20 Aug 2014 12:49:39 +1000

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,

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

---

From: William Chow <[email-masked]>
Date: Thu, 21 Aug 2014 21:27:18 +0000

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:[email-masked]] 
Sent: Tuesday, August 19, 2014 7:50 PM
To: Martin Thomson
Cc: Mike Bishop; HTTP Working Group
Subject: Re: Push and Caching

Cheers,

---

From: Mike Bishop <[email-masked]>
Date: Thu, 21 Aug 2014 21:47:04 +0000

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:[email-masked]] 
Sent: Thursday, August 21, 2014 2:27 PM
To: Mark Nottingham; Martin Thomson
Cc: Mike Bishop; HTTP Working Group
Subject: RE: Push and Caching

--Will

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

Cheers,

---

From: Patrick McManus <[email-masked]>
Date: Thu, 21 Aug 2014 20:20:19 -0400

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 <[email-masked]>
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.
>
> 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
>
> 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.
>
> 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:

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 22 Aug 2014 11:29:11 +1000

See:
  https://github.com/http2/http2-spec/pull/598

On 22 Aug 2014, at 10:20 am, Patrick McManus <[email-masked]> wrote:

> 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 <[email-masked]> wrote:

---

From: Martin Thomson <[email-masked]>
Date: Fri, 22 Aug 2014 10:17:35 -0700

>   https://github.com/http2/http2-spec/pull/598

I like this.  I'm going to leave it to sit for a while and then pull it in.

---

From: Mike Bishop <[email-masked]>
Date: Fri, 22 Aug 2014 17:30:05 +0000

"While the stream identified by the promised stream ID is still open" - meaning that as long as the client has asked for it before the server has finished sending it?  That's a fairly small amount of time, particularly if the resource is very small, but sounds like a good starting point.

If nothing else, that's a clearer standard that a proxy can use in the absence of knowledge of the client's request groupings.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 22 Aug 2014 10:57:33 -0700

> "While the stream identified by the promised stream ID is still open" - meaning that as long as the client has asked for it before the server has finished sending it?  That's a fairly small amount…

I'm sure that clients can fail to notice the END_STREAM flag for as
long as they need to in order to ensure that the various races resolve
in the right way...

Trying to determine how long the window is after END_STREAM arrives in
which clients can consider the response validated is nasty.  I don't
know how to finesse this other than turning a blind eye to small
violations, the likes of which you (and Firefox too) are committing in
this regard.

---

From: Mike Bishop <[email-masked]>
Date: Fri, 22 Aug 2014 18:56:33 +0000

Actually, Gabriel pointed out that since you can't validate the MAY from external observation, it should be non-normative, and the MUST NOT (presumably) duplicates an existing requirement that uncacheable things not be cached.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Friday, August 22, 2014 10:58 AM
To: Mike Bishop
Cc: Mark Nottingham; Patrick McManus; William Chow; HTTP Working Group
Subject: Re: Push and Caching

> "While the stream identified by the promised stream ID is still open" - meaning that as long as the client has asked for it before the server has finished sending it?  That's a fairly small amount…

I'm sure that clients can fail to notice the END_STREAM flag for as long as they need to in order to ensure that the various races resolve in the right way...

Trying to determine how long the window is after END_STREAM arrives in which clients can consider the response validated is nasty.  I don't know how to finesse this other than turning a blind eye to small violations, the likes of which you (and Firefox too) are committing in this regard.

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 24 Aug 2014 17:42:39 +1000

> violations, the likes of which you (and Firefox too) are committing in

Yeah, this was by far the trickiest bit; the caching model is really only built for client-driven traffic, server push inverts all of the assumptions and creates some nasty corner cases. The best we can do is wave hands about a bit and try to make sure there isn't too much implementation divergence... 

I'm OK with that mostly because if you push something with CC: no-cache and it isn't considered valid five seconds later, well, you got what you asked for, didn't you?

Cheers,

---

From: Greg Wilkins <[email-masked]>
Date: Sun, 24 Aug 2014 18:44:02 +1000

On 24 August 2014 17:42, Mark Nottingham <[email-masked]> wrote:

> I'm OK with that mostly because if you push something with CC: no-cache
> and it isn't considered valid five seconds later, well, you got what you
> asked for, didn't you?

Hmmm that makes me think.... is there some way the client could give some
feedback to the server so it knows if a pushed resource was used or not?
It does not need to be timely, but it would be good to log so that servers
can know if their push strategies are working with the current crop of
browsers / caches etc.

It would be bad if we created a universe where server developers think they
are really smart and push all sorts of resources that we never find out if
they are used or not.

Maybe we could add a flag to push promise, that if set would cause a pushed
resource usage summary to be sent, either after a period or when the
connection is closed.   Or is there some other way we can monitor the
success/failure of push?

cheers

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 24 Aug 2014 18:52:16 +1000

That feels like it'd fit better in the web perf wg's work, eg resource timing. 

Sent from my iPhone

> On 24 Aug 2014, at 6:44 pm, Greg Wilkins <[email-masked]> wrote:
> 
> 
> Hmmm that makes me think.... is there some way the client could give some feedback to the server so it knows if a pushed resource was used or not?  It does not need to be timely, but it would be good to log so that servers can know if their push strategies are working with the current crop of browsers / caches etc.
> 
> It would be bad if we created a universe where server developers think they are really smart and push all sorts of resources that we never find out if they are used or not.
> 
> Maybe we could add a flag to push promise, that if set would cause a pushed resource usage summary to be sent, either after a period or when the connection is closed.   Or is there some other way we can monitor the success/failure of push?
> 
> cheers
> 
> 
> 
> --

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 25 Aug 2014 10:01:01 +1000

I made those requirements because we're really stepping outside the bounds of the traditional HTTP caching model here, although I do see Gabriel's point. I'm happy if the editor wants to adjust.

Cheers,

---

From: Martin Thomson <[email-masked]>
Date: Mon, 25 Aug 2014 09:44:50 -0700

> "While the stream identified by the promised stream ID is still open" - meaning that as long as the client has asked for it before the server has finished sending it?  That's a fairly small amount…

How would people feel if I removed that clause.  They can be
considered validated.  The period over which that validation applies
is then no different to a regular request/response exchange, which
suffers all of the same sorts of thorny and ambiguous validity issues.
(i.e., By avoiding an attempt to define validity expressly, we're not
making it worse, even if we're not tackling the issue fully.)

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 26 Aug 2014 08:58:29 +1000

> making it worse, even if we're not tackling the issue fully.)

You mean removing the entire sentence, or just the clause quoted above? 

Just removing the clause leaves it open-ended, and some might read it as giving permission to make it indefinite.

Removing the entire sentence makes me less uncomfortable — but I still think some implementation guidance would be useful.

Remember — we’re talking about how long the HTTP cache can consider the response valid, not how the application using it can reuse that response (as browsers and intermediaries already do quite a bit).

Regards,

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 25 Aug 2014 16:13:03 -0700

> You mean removing the entire sentence, or just the clause quoted above?

I was thinking just the quoted clause.  I think that we need this to
cover the no-cache case (and must-revalidate), but I don't think that
we need to fix the problem.

BEFORE:
Pushed responses are considered successfully validated on the origin
server (...) while the stream identified by the promised stream ID is
still open.

AFTER:
Pushed responses are considered successfully validated on the origin
server (...).

How about the past tense instead?

TAKE TWO:
Pushed responses are considered successfully validated on the origin
server (...) at the time that the response is generated.

Does this avoid the unended implication?

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 26 Aug 2014 09:18:02 +1000

> server (...) at the time that the response is generated.

Blech, but yes, that works.

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 26 Aug 2014 12:48:12 +1000

> server (...) at the time that the response is generated.

I'm good with this one.     I like the instantaneous nature of it.

Any attempt to define the ongoing validity of a resource implies that
something will be checking that on the server side and overlaps with the
cache control headers.

cheers

---

From: William Chow <[email-masked]>
Date: Tue, 26 Aug 2014 05:04:25 +0000

Is “validated” the right term? It seems this could be confused with cache validation, which is only applicable to a cached response and is generally/intuitively viewed as a client-initiated action.

Also, which response is the point of reference for validity/freshness? The proposed sentence seems to refer to a pushed response being “validated” at the time that the pushed response itself was generated. I assume we’d actually want to treat the pushed responses to be fresh at the time the response for the associated/original request was generated.

--Will

From: Greg Wilkins [mailto:[email-masked]]
Sent: Monday, August 25, 2014 7:48 PM
To: Martin Thomson
Cc: Mark Nottingham; Mike Bishop; Patrick McManus; William Chow; HTTP Working Group
Subject: Re: Push and Caching

On 26 August 2014 09:13, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:
TAKE TWO:
Pushed responses are considered successfully validated on the origin
server (...) at the time that the response is generated.

Any attempt to define the ongoing validity of a resource implies that something will be checking that on the server side and overlaps with the cache control headers.

cheers

--
Greg Wilkins <[email-masked]<mailto:[email-masked]>>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 26 Aug 2014 15:07:15 +1000

Well, we’re trying to tie in the concept of cache validation (which is deeply part of the caching model) to this unnatural (to the caching model) interaction. Not sure how to do that without saying “validation”…

Cheers,

---

From: William Chow <[email-masked]>
Date: Tue, 26 Aug 2014 05:18:35 +0000

Can "fresh" work? I agree that it perhaps implies caching as well, but at least it avoids the notion that the server actually performed any validation (which it could not, without the client providing validators for the pushed responses).

--Will

-----Original Message-----
From: Mark Nottingham [mailto:[email-masked]] 
Sent: Monday, August 25, 2014 10:07 PM
To: William Chow
Cc: Greg Wilkins; Martin Thomson; Mike Bishop; Patrick McManus; HTTP Working Group
Subject: Re: Push and Caching

Well, we're trying to tie in the concept of cache validation (which is deeply part of the caching model) to this unnatural (to the caching model) interaction. Not sure how to do that without saying "validation"...

Cheers,

On 26 Aug 2014, at 3:04 pm, William Chow <[email-masked]> wrote:

> Is "validated" the right term? It seems this could be confused with cache validation, which is only applicable to a cached response and is generally/intuitively viewed as a client-initiated action.
>  
> Also, which response is the point of reference for validity/freshness? The proposed sentence seems to refer to a pushed response being "validated" at the time that the pushed response itself was generated. I assume we'd actually want to treat the pushed responses to be fresh at the time the response for the associated/original request was generated.
>  
> --Will
>  
> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that 
> scales http://www.webtide.com  advice and support for jetty and cometd.

---

From: Matthew Kerwin <[email-masked]>
Date: Tue, 26 Aug 2014 15:49:26 +1000

On 26 August 2014 15:18, William Chow <[email-masked]> wrote:
> Can "fresh" work? I agree that it perhaps implies caching as well,
> but at least it avoids the notion that the server actually performed
> any validation (which it could not, without the client providing
> validators for the pushed responses).

"Pushed responses are considered fresh on the origin server (...) at
the time that the response is generated." Makes sense to me, although it
starts to sound a bit no-brainish.

​And regarding your other question:​

> Also, which response is the point of reference for
> validity/freshness? The proposed sentence seems to refer to a pushed
> response being "validated" at the time that the pushed response
> itself was generated. I assume we'd actually want to treat the pushed
> responses to be fresh at the time the response for the
> associated/original request was generated.

It can only be fresh at the time the pushed response itself is
generated, surely. The original response triggered the *need* for the
pushed resource, but there's nothing stopping the value of that pushed
resource changing between the need being determined and bytes being
transmitted.

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 26 Aug 2014 16:48:32 +1000

"fresh on the origin server" isn't relevant; what's relevant is whether they're fresh in the cache, and that can be determined by examining the response.

The issue at hand is whether the pushed response needs to be revalidated, as per the definition of no-cache.

---

From: Chris Drechsler <[email-masked]>
Date: Tue, 26 Aug 2014 13:30:58 +0200

I think pushed responses must not use "no-cache" in Cache-Control. Then 
there is no revalidation problem.

Chris

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 26 Aug 2014 09:44:00 -0700

> The issue at hand is whether the pushed response needs to be revalidated, as per the definition of no-cache.

"A recipient cache SHOULD consider a pushed response to be valid for the
duration of the connection (or until it is replaced during that connection)
even if the pushed response contains a "no-cache" cache directive."

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 26 Aug 2014 09:59:35 -0700

> even if the pushed response contains a "no-cache" cache directive."

Er, probably easier to be generic to all directives that control freshness:

"A recipient cache SHOULD consider a pushed response to be valid for the
duration of the connection (or until it is replaced during that connection)
even if the pushed response contains cache directives that would normally
indicate that the response is immediately stale."

....Roy

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Aug 2014 11:37:33 -0700

> indicate that the response is immediately stale."

Given the long-lived nature of HTTP/2 connections is this really the
right bound on validity?  It's not as though the server is guaranteed
an opportunity to replace/invalidate the response.

I'm a little leery of implying something about regular response
validity in this context.  I couldn't find anything concrete in RFC
7234 about the period over which a response can be considered valid
once it arrives at the client.  The best I could find was: "A cache
need not validate a response that merely became stale in transit."

If anything 7234 uses validation in the instantaneous sense
exclusively.  Freshness seems to be the only concept that is
associated with a time period, but we're carefully avoiding that here.
This, to my reading, is breaking new ground.  And people are right to
notice the prefetch and request combining features as having
interactions with this, even though those seem to be confined to web
use cases.

I don't think that this is a defect of RFC 7234, but it's an issue
that I'd prefer to see addressed more comprehensively than just for
push.

...and that's mainly why I suggested the "at the time that the
response is generated".

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 26 Aug 2014 12:05:03 -0700

> an opportunity to replace/invalidate the response.

I would expect them to push another.  Isn't that sufficient?

> need not validate a response that merely became stale in transit."

Hmm, that effectively has the same meaning as what I proposed -- a
pushed response can be considered in-transit until it is used.

> ...and that's mainly why I suggested the "at the time that the

But that has no value to the recipient.  Validation only occurs when
a response is used, and it is impossible to use a response at the time
it was generated.

I think we should just accept that a server is not going to push a
response if it expects a validation round-trip to be required for
its use.  Hence, let the server send another push if it wants to
invalidate what it already sent.

....Roy

---

From: Michael Sweet <[email-masked]>
Date: Tue, 26 Aug 2014 16:00:40 -0400

Push has always been talked about in the context of a server pushing data that the client would need to GET anyways, so why shouldn't we just use the same cache semantics for both a GET response and an pushed response?

> ...and that's mainly why I suggested the "at the time that the

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: William Chow <[email-masked]>
Date: Tue, 26 Aug 2014 20:19:46 +0000

> interactions with this, even though those seem to be confined to web 

7234 refers to a response being valid in direct correspondence to a specific request. With HTTP2 and server push, there can be multiple responses that directly correspond to that "original request" (this is the term used in the HTTP2 draft). For server push to be effective, we really need this validity/freshness to expand to be 1-N relationship between the original request and all of the responses returned from the server for that request. We don't need to state how that is done (e.g. UAs/clients may implement a navigation context) but it doesn't help the recipient to understand the scope of validity for a pushed response if that validity is not relative to anything but itself.

> server (...) at the time that the response is generated.

So, going back to the proposed language, it seems we can address this for HTTP2 because we have the notion of the "original request", such as: "Pushed responses are considered valid (...) at the time that the response for the original request is generated."

--Will

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Aug 2014 14:14:51 -0700

> I would expect them to push another.  Isn't that sufficient?

It might be.  Though you have to accept that the opportunity to push
might not reappear.

> pushed response can be considered in-transit until it is used.

If that is the case, that's writing a blank check.  Practically
speaking, that's how people use responses anyway: they use them when
they are ready to (which is usually as quickly as possible :).  The
point being not to prevent use, but to discourage reuse.

So if you are ok with that, then I am.  I still don't think that
binding to the connection lifetime is particularly useful though.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Aug 2014 14:15:56 -0700

On 26 August 2014 13:19, William Chow <[email-masked]> wrote:
> With HTTP2 and server push, there can be multiple responses that directly correspond to that "original request" (this is the term used in the HTTP2 draft).

That's not right.  Server push always provides a request.  The only
difference is that it is synthesized by the server.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 26 Aug 2014 14:22:53 -0700

> binding to the connection lifetime is particularly useful though.

Yes, it was just the most convenient lifetime I could think of ...
"used at least once" is probably the minimum.  I would be surprised
if anyone pushed something that was not "good until replaced",
and I suspect UAs will use the configured default of "check at most
once in 24 hours or after restart".  But that's just guessing.

....Roy

---

From: William Chow <[email-masked]>
Date: Tue, 26 Aug 2014 23:07:14 +0000

>That's not right.  Server push always provides a request.  The only difference is that it is synthesized by the server.

I am referring to this paragraph in 8.2:

"HTTP/2 allows a server to pre-emptively send (or "push") responses (along with corresponding "promised" requests) to a client in association with a previous client-initiated request. This can be useful when the server knows the client will need to have those responses available in order to fully process the response to the original request."

Note that I didn't say the server *didn't* also push the request. I am only referring to the notion stated above that those pushed responses are "in association with a previous client-initiated request". Perhaps you disagree with my use of the term "correspond", so "in association" is fine by me. 

Upon further reflection, the time of the generation of a pushed response is going to be effectively the same time as the generation of the response to the original request, so perhaps there isn't much practical difference between your proposed text and mine. What I am hoping we'd be able to do is to include language that describes the relationship between the original request/response and the pushed responses, so that caches have guidance on when it is safe to serve a pushed response when the client-initiated request is actually received later from the UA. 

For your proposed text that says a pushed response is validated at the time it was generated, this seems so obvious as to not have any value for the no-cache case. Specifically, it seems that a pushed no-cache response should only be valid when *used* in combination with the response it was pushed with. I think this is what Roy F. was alluding to in his other response (about not preventing use, but to discourage reuse). While we can call out the no-cache case specifically, it seems we don't really need to if we had language that coupled the pushed responses's validity with their associated original request/response.

--Will

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 27 Aug 2014 09:14:03 +1000

> I would expect them to push another.  Isn't that sufficient?

I'm with Martin on this one.

Resources are pushed in the context of a GET request, not in the context of
a connection.

Their should be no obligation on the server to monitor the status of the
pushed resource beyond the time it is sent, as that could add up to a
significant active burden on the server to look for file changes in pushed
resources, and other resources may not even be possible to now if they have
changed without attempting to regenerate them.

More importantly, once the initial GET has finished, there is no context in
which to either form the 'fake' request to which the server is pushing a
response, nor a stream on which is can be pushed.

I think the effect of pushing a no-cache resource should be as if the
client had just received a response to a request that it made itself during
the processing of the scoping GET.

cheers

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 27 Aug 2014 09:20:33 +1000

On 27 August 2014 09:07, William Chow <[email-masked]> wrote:

> Specifically, it seems that a pushed no-cache response should only be
> valid when *used* in combination with the response it was pushed with.

I think there is merit in language that associates the validity with the
response on which it was pushed.

This is a bit tangled.... but best I can do:

A recipient cache handling of a pushed response SHOULD be indistinguishable
from the
handling of a response received to a referred request made why processing
the original
response on which the pushed promise was received.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Aug 2014 16:22:13 -0700

On 26 August 2014 16:07, William Chow <[email-masked]> wrote:
> What I am hoping we'd be able to do is to include language that describes the relationship between the original request/response and the pushed responses, so that caches have guidance on when it is safe to serve a pushed response when the client-initiated request is actually received later from the UA.

Any association between a request and any server pushes it generates
is largely incidental from the perspective of what we are talking
about right now (caching, validity, general usability).  Each
request-response pair can be considered completely independent in that
regard, in fact, in virtually all respects.  Caches can and should
treat each independently.

The only tricky part is to determine when it is best to push something
when you don't have any cues from the server.  You could, for
instance, remember the set of pushed resources that came in response
to a given request and push those too, or you could build new
heuristics around push for origin servers that don't generate it.
That's something that is up to you.

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 27 Aug 2014 12:27:42 +1000

> treat each independently.

Which is why I think wording that relates handling of a pushed response to
the normal handling of a requested response is the way to go.   If the
validity/use/visibility of a request response can be seen beyond the scope
of the associated request, then so to can a pushed response.

We want pushed resources to be handled no differently than if the client
had requested them.  In the case of a no-cache response, the client does
handle with an associated to the current page, but if there is no
association for other responses, than saying pushed response handling is
indistinguishable from requested response handling, captures that.

cheers