Subject: Acknowledging pushed content

From: Phil Lello <[email-masked]>
Date: Thu, 7 Apr 2016 21:13:27 +0100

I'm not aware if this being covered before; has any consideration been
given to acknowledging pushed content?

The scenario I have in mind is retrieving multiple sequential records over
AJAX. It could help latency for a server to know when records have been
consumed so that it can push the next set of records.

Is there interest in pursuing this feature?

Best wishes,

Phil Lello

---

From: Martin Thomson <[email-masked]>
Date: Thu, 7 Apr 2016 17:39:50 -0300

On 7 April 2016 at 17:13, Phil Lello <[email-masked]> wrote:
> I'm not aware if this being covered before; has any consideration been given
> to acknowledging pushed content?

Yes, considerable thought has been put into this problem.  You will
one example of that process here:

https://tools.ietf.org/html/draft-ietf-webpush-protocol-04#section-7.2

In other words, the application can do this itself.

---

From: Phil Lello <[email-masked]>
Date: Fri, 8 Apr 2016 17:00:37 +0100

> In other words, the application can do this itself.

That's a good solutuion, but doesn't seem a good fit for this use case
since the records aren't events. I omitted to specify HTTP/2 push as
opposed to other push mechanisms. I'll explain the scenario further.

In both a traditional desktop browser environment and server-to-server web
services, paging is often used when dealing with a set of results. To
optimise responsiveness, a server could send page 1 and push page 2. The
objective here is to tell the server when page 2 is requested by the client
so that it can prepare/push page 3. In a browser environment, this could be
implemented with client-side application logic, but DELETE seems like the
wrong action. In a server-to-server environment for a public webservice,
where there will be multiple client implementation, it seems better to
handle this with a 'push-consumed' frame at the HTTP/2 level, so a server
can try to keep pipelines full for clients without changing
application-level semantics.

Does a separate solution seem appropriate here, or should we aim to
converge?

---

From: Mike Bishop <[email-masked]>
Date: Fri, 8 Apr 2016 16:33:06 +0000

An extension could define an informative frame, certainly.  There’s no requirement that the server understand, so the client could send speculatively or define a setting that hints to the client whether it should bother.

From: Phil Lello [mailto:[email-masked]]
Sent: Friday, April 8, 2016 9:01 AM
To: Martin Thomson <[email-masked]>
Cc: HTTP Working Group <[email-masked]>
Subject: Re: Acknowledging pushed content

On Thu, Apr 7, 2016 at 9:39 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

That's a good solutuion, but doesn't seem a good fit for this use case since the records aren't events. I omitted to specify HTTP/2 push as opposed to other push mechanisms. I'll explain the scenario further.
In both a traditional desktop browser environment and server-to-server web services, paging is often used when dealing with a set of results. To optimise responsiveness, a server could send page 1 and push page 2. The objective here is to tell the server when page 2 is requested by the client so that it can prepare/push page 3. In a browser environment, this could be implemented with client-side application logic, but DELETE seems like the wrong action. In a server-to-server environment for a public webservice, where there will be multiple client implementation, it seems better to handle this with a 'push-consumed' frame at the HTTP/2 level, so a server can try to keep pipelines full for clients without changing application-level semantics.
Does a separate solution seem appropriate here, or should we aim to converge?

---

From: Martin Thomson <[email-masked]>
Date: Fri, 8 Apr 2016 14:30:08 -0300

> application-level semantics.

I don't see any way around the problem here.  The consumption of the
resource is not what you are looking to trigger on; that could occur
long before the navigation happens.  The event of interest exists at
the application layer.  Use an application layer mechanism.