Practically I think there is a difference in how they are handled.

A "message" may be comprised by a sequence of HEADERS and DATA frames
interspersed in a stream. This flag would be handled at the application
layer.

The "CONTINUES" bit is really reserved to inform the header compressor that
the frame is incomplete. The application has no knowledge that its header
map, when encoded onto the wire, had to be split across multiple frames due
to the frame size limits.


On Tue, Jun 18, 2013 at 11:26 AM, martinthomson <notifications@github.com>wrote:

> In draft-ietf-httpbis-http2.xml:
>
> > -
> > -          <t>
> > -            HEADERS+PRIORITY uses the same flags as the HEADERS frame, except that a
> > -            HEADERS+PRIORITY frame with a CONTINUES bit MUST be followed by another HEADERS+PRIORITY
> > -            frame.  See <xref target="HEADERS">HEADERS frame</xref> for any flags.
> > +            The HEADERS frame defines the following type-specific flags:
> > +            <list style="hanging">
> > +              <t hangText="FINAL (0x1):">
> > +                Bit 1 (the least significant bit) being set indicates that this frame is the last
> > +                the endpoint will send on the identified stream.  Setting this flag causes the
> > +                stream to enter the <xref target="StreamHalfClose">half-closed state</xref>.
> > +              </t>
> > +              <t hangText="MSG_DONE (0x2):">
> > +                Bit 2 being set indicates that this frame comprises a message boundary.
> > +              </t>
> > +              <t hangText="CONTINUES (0x4):">
>
> While there might be a semantic difference, the question is whether it is
> a valuable one. What value is there in having a MSG_DONE flag that only
> implies "end of message"?
>
> But then I'm not sure what you do with a sequence of frames that form a
> message, if you aren't concatenating them. That's certainly the desired
> behavior for web sockets (though it's not strictly concatenation in a
> practical sense, it's more like it's adding those bytes to the message
> stream).
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/http2/http2-spec/pull/131/files#r4755529>
> .
>