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

Re: Design: Rename FRAME_TOO_LARGE to FRAME_SIZE_ERROR

From: (wrong string) 陈智昌 <willchan@chromium.org>
Date: Wed, 19 Jun 2013 10:28:48 -0700
Message-ID: <CAA4WUYgKJwhQGsyUyJzcaqy4C-iETsvqb9yPNax5JSixCNCu=A@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Jeff Pinner <jpinner@twitter.com>, Roberto Peon <grmocg@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Wed, Jun 19, 2013 at 10:22 AM, Martin Thomson
<martin.thomson@gmail.com>wrote:

> On 19 June 2013 09:32, Jeff Pinner <jpinner@twitter.com> wrote:
> > 1 byte per data frame is completely legal at both the framing layer and
> the
> > application layer. I believe the only illustrating examples here are
> > something like sending a 7 byte PING frame or a 3 byte WINDOW_UPDATE
> frame.
> > You have received the entire frame, it is just malformed.
>
> So, I have a question:  is there an actionable difference between
> FRAME_SIZE_ERROR and PROTOCOL_ERROR.  Noting that neither RST_STREAM,
> nor GOAWAY, have a way to indicate which frame was in error, there
> isn't much that is actionable in either case.  I believe that the
> action in both cases is the same: go and debug your stack.
>

Actionable difference: it tells you what part of your stack to debug.
PROTOCOL_ERROR is terrible :( Everytime we generate a PROTOCOL_ERROR, we
have felt we wanted to add a debug string (that opaque byte sequence we
discussed earlier) so we could figure out what was wrong.


>
> That leads me to conclude that this is error code proliferation for no
> good reason.
>
>
Received on Wednesday, 19 June 2013 17:29:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:13 UTC