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

RE: draft-ietf-httpbis-http2-latest, 6.2 HEADERS, 6.10 CONTINUATION, END_SEGMENT (0x2)

From: <K.Morgan@iaea.org>
Date: Thu, 3 Jul 2014 22:20:42 +0000
To: <martin.thomson@gmail.com>, <hurtta-ietf@elmme-mailer.org>
CC: <ietf-http-wg@w3.org>
Message-ID: <0356EBBE092D394F9291DA01E8D28EC2011870686E@sem002pd>
This is _exactly_ what Greg has been saying about CONTINUATION for a couple of weeks.  It's plain confusing to have an END_STREAM flag that doesn't actually end the stream.  Kari certainly will *not* be the last to be confused.


From: martin.thomson@gmail.com [martin.thomson@gmail.com]
Sent: 03 July 2014 23:14
To: Kari Hurtta
Cc: HTTPBIS working group mailing list
Subject: Re: draft-ietf-httpbis-http2-latest, 6.2 HEADERS, 6.10 CONTINUATION,  END_SEGMENT (0x2)

On 2 July 2014 21:51, Kari Hurtta <hurtta-ietf@elmme-mailer.org> wrote:
> What "A HEADERS frame that is followed by CONTINUATION frames carries
> the END_STREAM flag that signals the end of a stream." that is exactly
> supposed that say:
>    - END_STREAM (0x1)  flag is implicti on CONTINUATION frame
> or
>    - END_STREAM (0x1)  flag bit is actually set on CONTINUATION frame
>      ( although it is not mentioned on section 6.10   CONTINUATION )

I had a little trouble following this email.  But I think that this is
a problem of misunderstanding: CONTINUATION frames don't carry any
frame state.  All the important flags (and END_SEGMENT) are carried on
the frame that precedes CONTINUATION.  The only flag CONTINUATION
carries is END_HEADERS.

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.
Received on Thursday, 3 July 2014 22:21:19 UTC

This archive was generated by hypermail 2.3.1 : Monday, 9 September 2019 17:48:19 UTC