W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013


From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 23 Jul 2013 16:43:50 -0700
Message-ID: <CABkgnnUK45jVj1f=QuJnE7w3gSWJZ_jAPq=87SLyvyGYxUt0kw@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC