- From: Mike Bishop <Michael.Bishop@microsoft.com>
- Date: Fri, 8 Apr 2016 16:33:06 +0000
- To: Phil Lello <phil@dunlop-lello.uk>, Martin Thomson <martin.thomson@gmail.com>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CH1PR03MB191623812EAF7A08AF01BF0A87910@CH1PR03MB1916.namprd03.prod.outlook.com>
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:phil@dunlop-lello.uk] Sent: Friday, April 8, 2016 9:01 AM To: Martin Thomson <martin.thomson@gmail.com> Cc: HTTP Working Group <ietf-http-wg@w3.org> Subject: Re: Acknowledging pushed content On Thu, Apr 7, 2016 at 9:39 PM, Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>> wrote: On 7 April 2016 at 17:13, Phil Lello <phil@dunlop-lello.uk<mailto:phil@dunlop-lello.uk>> 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. 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?
Received on Friday, 8 April 2016 16:33:36 UTC