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

Re: BLOCKED frame specification

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Thu, 17 Apr 2014 01:19:01 +1200
Message-ID: <534E8345.8020501@treenet.co.nz>
To: ietf-http-wg@w3.org
On 16/04/2014 10:08 p.m., Roberto Peon wrote:
> Bleh.
> We have address space in the frame opcodes, lets use that instead of adding
> new semantics to things which are unstructured.

Indeed. Since the editors or WG decided that frames shall not be
extensible there are opcodes to spare in abundance. Whereas ping codes
are potentially open to extensions still by other drafts.

> The only bit of information that is needed is when the remote end is not
> blocked (confirming that it was blocked intentionally/whatever seems like a
> waste). That is enough for tuning and debugging.

Confirming that it is not-blocked could be as simple as sending the next
frame for the stream in response to the BLOCKED query. Or perhapse an
empty non-final DATA frame if one wishes.


Received on Wednesday, 16 April 2014 13:19:36 UTC

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