W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: BLOCKED frame specification

From: Yoav Nir <ynir.ietf@gmail.com>
Date: Wed, 9 Apr 2014 11:59:34 +0300
Cc: Martin Thomson <martin.thomson@gmail.com>, Mark Nottingham <mnot@mnot.net>, Hasan Khalil <mian.hasan.khalil@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <6A4EFD38-ED6C-4B8B-AD54-1AE841A203C4@gmail.com>
To: David Krauss <potswa@gmail.com>

On Apr 9, 2014, at 11:53 AM, David Krauss <potswa@gmail.com> wrote:

> On 2014–04–09, at 4:47 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
>> I want the information that it conveys, and this seems like a workable way of providing it.  I don’t think a RST_STREAM code or GOAWAY data can replace this, because they will only occur after a timeout. The BLOCKED frame can be sent after a much shorter time (1 RTT?) or even immediately.
>> On second thought, “debugging” is probably more important, because correct implementations should never reach this state.
> Then why doesn’t PING suffice? You can send it at any time and there’s space for an implementation-defined payload value.

That only tells me if the connection is working, not if the resources are not coming because of some server issue (like trouble connecting to a back-end database) or because of flow control.
Received on Wednesday, 9 April 2014 09:00:04 UTC

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