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

Re: Design Issue: Merge RST_STREAM and GOAWAY into a single ERROR frame type

From: Roberto Peon <grmocg@gmail.com>
Date: Fri, 3 May 2013 14:25:58 -0700
Message-ID: <CAP+FsNcN4OyqP=WkmsYUG+m9EHrTuELHx40n7S6wRb6F7L73FQ@mail.gmail.com>
To: William Chan (陈智昌) <willchan@chromium.org>
Cc: James M Snell <jasnell@gmail.com>, Jeff Pinner <jpinner@twitter.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
I also find the current way more obvious-- in wireshark and similar traces,
it is far easier to pick out the different opcode type (which is typically
rendered as the textual name of the opcode) as opposed to the numeric value
in some field.

-=R


On Fri, May 3, 2013 at 2:12 PM, William Chan (陈智昌) <willchan@chromium.org>wrote:

> Sorry, my implication is that I don't see any objective determination of
> what's simpler here, just subjective views of which many people can have an
> opinion. But if there's consensus on doing this, then by all means, let's
> do it. I for one disagree and find the current way simpler :)
>
>
> On Fri, May 3, 2013 at 6:08 PM, James M Snell <jasnell@gmail.com> wrote:
>
>> There is no bikeshedding going on at all. I made the motivation for
>> this clear up front: it's a simplification that addresses three
>> specific items. Note: there is an existing editorial note in the
>> existing draft that calls out the fact that we have no non-terminal
>> method of communicating non-stream related errors. If we can address
>> that item while also simplifying things a bit, then fantastic.
>>
>> On Fri, May 3, 2013 at 2:01 PM, William Chan (陈智昌)
>> <willchan@chromium.org> wrote:
>> > This is a thread ripe for bikeshedding. Is there any major issue worth
>> > solving?
>> >
>> > If we're going to paint our bike sheds, my take is keep whatever color
>> the
>> > bike shed already has unless it really offends a number of people.
>> >
>> >
>> > On Fri, May 3, 2013 at 5:53 PM, James M Snell <jasnell@gmail.com>
>> wrote:
>> >>
>> >> Speaking candidly, if we find ourselves requiring more than 8 boolean
>> >> flags on an error frame we should all just quit and go home.
>> >>
>> >> On Fri, May 3, 2013 at 1:34 PM, Jeff Pinner <jpinner@twitter.com>
>> wrote:
>> >> > IIRC, when this was brought up at the last F2F the rational for NOT
>> >> > doing
>> >> > this was that frame types were cheaper than flags (256 frame types, 8
>> >> > flags).
>> >> >
>> >> > That being said I think we should consider combining them :)
>> >> >
>> >> >
>> >> > On Fri, May 3, 2013 at 1:04 PM, James M Snell <jasnell@gmail.com>
>> wrote:
>> >> >>
>> >> >> As a simplification, I'd like to suggest that we merge the
>> RST_STREAM
>> >> >> and GOAWAY frames into a single ERROR frame with the following
>> >> >> definition:
>> >> >>
>> >> >>  0                   1                   2                   3
>> >> >>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>> >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >> >> |                      Error Code (32)                          |
>> >> >> +---------------------------------------------------------------+
>> >> >> |X|                  Last-Stream-ID (31)                        |
>> >> >> +-+-------------------------------------------------------------+
>> >> >>
>> >> >> (note that this flips the field order from the GOAWAY frame)
>> >> >>
>> >> >> A frame-specific GOAWAY flag bit (0x2) would be defined for the
>> frame,
>> >> >> and the Last-Stream-ID field would only be included in the frame
>> data
>> >> >> if this flag was set.
>> >> >>
>> >> >> This does a couple of things for us:
>> >> >>
>> >> >> 1. It simplifies the error handling and reduces the number of core
>> >> >> frame
>> >> >> types.
>> >> >> 2. It allows us to terminate a stream and terminate the session in a
>> >> >> single frame if necessary
>> >> >> 3. It gives us a way of reporting non-terminal session errors
>> >> >> (currently RST_STREAM is forbidden to use stream id #0 and GOAWAY is
>> >> >> always terminal).
>> >> >>
>> >> >
>> >>
>> >
>>
>
>
Received on Friday, 3 May 2013 21:26:25 UTC

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