RE: BLOCKED frame specification

The BLOCKED frame is not something we are interested in and would rather not add another late feature to the spec.  The standard is already slipping the schedule and we need to stop adding to the spec.



Thanks!!



-Rob

From: Roberto Peon [mailto:grmocg@gmail.com]
Sent: Wednesday, April 9, 2014 2:30 AM
To: Yoav Nir
Cc: David Krauss; HTTP Working Group
Subject: Re: BLOCKED frame specification

imho, this is useful for tuning, not just debugging.

And we've found that tuning is annoyingly difficult to get right.

Obviously I want this, in case that wasn't common knowledge already :)
-=R

On Wed, Apr 9, 2014 at 2:17 AM, Yoav Nir <ynir.ietf@gmail.com<mailto:ynir.ietf@gmail.com>> wrote:

On Apr 9, 2014, at 12:02 PM, David Krauss <potswa@gmail.com<mailto:potswa@gmail.com>> wrote:

>
> On 2014-04-09, at 4:59 PM, Yoav Nir <ynir.ietf@gmail.com<mailto:ynir.ietf@gmail.com>> wrote:
>
>> 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.
>
> Use the implementation-defined payload value. It's not portable but you don't need portability for debugging.
Looking at section 6.7 of -11 I don't see any implementation-defined payload value, just some opaque data that the receiver should copy into its response.

Even if there was, I would be debugging my implementation against some other implementation. Not against my own.

Yoav