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

Re: BLOCKED frame specification

From: Roberto Peon <grmocg@gmail.com>
Date: Wed, 9 Apr 2014 02:30:23 -0700
Message-ID: <CAP+FsNd6=5bVB4SRzQNczfQ7PBBpT=yjcXHqj8=tS+KKrpCbTA@mail.gmail.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Cc: David Krauss <potswa@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
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> wrote:

>
> On Apr 9, 2014, at 12:02 PM, David Krauss <potswa@gmail.com> wrote:
>
> >
> > On 2014-04-09, at 4:59 PM, Yoav Nir <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
>
>
>
Received on Wednesday, 9 April 2014 09:30:49 UTC

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