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:47:51 +0300
Cc: Mark Nottingham <mnot@mnot.net>, Hasan Khalil <mian.hasan.khalil@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <421217B0-3C31-4E62-B0C2-96A18F6F72E9@gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>

On Apr 9, 2014, at 12:15 AM, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 8 April 2014 12:02, Yoav Nir <ynir.ietf@gmail.com> wrote:
>> It looks good to me, except I would replace the word “debugging” with the word “troubleshooting”.  The former is usually associated with implementation development, whereas the latter is associated with figuring out why my download keeps breaking up.
> Can I infer from this response that you want this feature Yoav?

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.

Received on Wednesday, 9 April 2014 08:48:23 UTC

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