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

Re: BLOCKED frame specification

From: Johnny Graettinger <jgraettinger@chromium.org>
Date: Wed, 16 Apr 2014 11:07:52 -0400
Message-ID: <CAEn92TopOTfaL8cVZDbJGpaEpFCwihe95pQweAsVxqu__B3yPQ@mail.gmail.com>
To: David Krauss <potswa@gmail.com>
Cc: Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
<resend from correct address>

On Wed, Apr 16, 2014 at 10:45 AM, David Krauss <potswa@gmail.com> wrote:

> On 2014–04–16, at 9:43 PM, Johnny Graettinger <jgraettinger@chromium.org>
> wrote:
> > I'm not sure what is meant by a BLOCKED "query". This is (and IMO should
> be) a unidirectional rather than query/response pattern.
> Is there really a point to notifying of blockage by default? Every
> dependent stream is blocked as long as its dependency (or another
> dependency up the hierarchy) is unblocked. How often does a client need to
> be reminded which streams remain blocked?
> The interesting information is whether something has been unblocked by the
> expected time. What is to be debugged is avoiding excessive dependencies
> (on the client side) and correct dependency resolution (on the server side).

I think there's a misunderstanding here. Priorities are about the relative
ordering of multiple *ready-to-write* streams. A sender can and certainly
should send a dependent stream frame, if that's what's available.

>  > I hesitate to suggest this, as I think Hasan's proposal is strictly
> better, but an alternative might be to send a single empty DATA frame under
> the blocked condition. This has the advantage of compatibility with the
> current spec: receivers must handle empty DATA frames anyway, and can
> choose to ignore the semantics. However it loses the explicitness of
> BLOCKED about whether it's stream or session flow control that's the
> culprit; the receiver would need to make a guess.
> An empty DATA frame will simply be coalesced (ignored) by the first
> intermediary.

That's fine. Flow control is also hop-by-hop.

Received on Wednesday, 16 April 2014 15:08:23 UTC

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