- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Tue, 23 Jul 2013 16:43:50 -0700
- To: Roberto Peon <grmocg@gmail.com>
- Cc: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>, Gábor Molnár <gabor.molnar@sch.bme.hu>, HTTP Working Group <ietf-http-wg@w3.org>
On 23 July 2013 15:38, Roberto Peon <grmocg@gmail.com> wrote: > I'm a proxy guy, actually. Everyone writing a stack deals with these problems at some level. Some will just have to worry about concurrency and queuing at a different layer, that's all :) After some offline discussion, I understand that we still (perhaps grudgingly) need a way to signal that a client is unwilling to receive pushes. However, that operates at two levels: a) a client is unwilling to receive pushes, ever b) a client is currently unwilling to receive pushes, but will accept promises (i.e., the requests) in the expectation that it can receive the corresponding responses in time The concern here is that setting the maximum concurrent streams to zero could be used to communicate either situation, and that sometimes the distinction is important. I think that onus is on Roberto to more effectively motivate the need for this distinction. If indeed we agree that the two cases are distinct, then we probably need to consider ways to communicate this distinction effectively. A separate setting that expressly disables push promise or limits the number of promises might work.
Received on Tuesday, 23 July 2013 23:44:18 UTC