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

From: Martin Thomson <[email-masked]>
Date: Thu, 3 Jul 2014 14:14:29 -0700

On 2 July 2014 21:51, Kari Hurtta <[email-masked]> 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.

---

From: <[email-masked]>
Date: Thu, 3 Jul 2014 22:20:42 +0000

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.

-keith

________________________________________
From: [email-masked] [[email-masked]]
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)

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.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 4 Jul 2014 08:58:47 -0700

On 3 July 2014 22:20, Kari Hurtta <[email-masked]> wrote:
> So now it is fixed.

Thanks.  I wasn't sure if that would help.

---

From: Kari Hurtta <[email-masked]>
Date: Fri, 04 Jul 2014 16:27:15 +0000

> Thanks.  I wasn't sure if that would help.

Yes, that fixed that first "item" on my mail:

| What I have missed ?
| 
| How END_SEGMENT is supposed to work when segment is supposed to end
| after headers and headers do not fit to one HEADERS frame ?

( If any new flags are added to HEADERS, then these flags
  also must be specified are they for that HEADER -frame
  or are they for combined HEADER + CONTINUATION frames. ) 

You quoted that another part of mai mail:

| 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:

That was partially misread from my side.

Yet about that first "item" on my mail:

That

| END_SEGMENT (0x2):
|
|     Bit 2 being set indicates that this frame is the last for the current segment. 

should probably be

>    Bit 2 being set indicates that this frame (and possible CONTINUATION frames)
>    are the last for the current segment. 

That part

|    END_SEGMENT, like END_STREAM, applies to a complete sequence of HEADERS and 
|    CONTINUATION frames. 

of course implies that but in that situation "this frame is the last for the 
current segment" is not exactly true.

Alternative that han be said same way than on "END_STREAM (0x1)" part:

> END_SEGMENT (0x2):
>
>    Bit 2 being set indicates that this header block is the last for the current 
>    segment.

That way there is not "this frame" but "this header block", which is easier
to understand as HEADER frame + CONTINUATION frames.

/ Kari Hurtta