Subject: RE: question about QPACK decode framing

From: Brian Swander <[email-masked]>
Date: Thu, 1 Nov 2018 15:27:09 +0000

>From our read of the current drafts:

It seems that in the drafts that the HEADERS frame is only for the compressed headers being sent on a real stream.
The encoder and decoder streams for QPACK are just the raw encodings as described in the QPACK spec without extra framing.  
If so, then on the decoding on the decoder stream, there is no way to know (a priori) that we have a complete set of headers, since there is no overall header length available.

Can someone please clarify.

Thanks
bs

-----Original Message-----
From: Dmitri Tikhonov <[email-masked]> 
Sent: Wednesday, October 31, 2018 2:15 PM
To: Brian Swander <[email-masked]>
Cc: [email-masked]
Subject: Re: question about QPACK decode framing

Hi Brian,

(I am assuming you're talking about processing the header block.)

The header block is in the HQ "HEADERS" frame which has a length.
Depending on your implementation, you may be able to tell if you have the complete header block buffered.

  - Dmitri.

On Wed, Oct 31, 2018 at 08:57:27PM +0000, Brian Swander wrote:
> Is there a way to determine that we are decoding a complete set of headers a priori?   I.e. is the "headers length" encoded anywhere?   Or does decode (control stream) just have to handle the case where we only have a partial header, and we just pend and wait for more data before continuing?
> 
> Thanks
> bs

---

From: Dmitri Tikhonov <[email-masked]>
Date: Thu, 1 Nov 2018 11:43:14 -0400

On Thu, Nov 01, 2018 at 03:27:09PM +0000, Brian Swander wrote:
> It seems that in the drafts that the HEADERS frame is only for the
> compressed headers being sent on a real stream.  The encoder and decoder
> streams for QPACK are just the raw encodings as described in the QPACK
> spec without extra framing.  If so, then on the decoding on the decoder
> stream, there is no way to know (a priori) that we have a complete
> set of headers, since there is no overall header length available.

QPACK uses two unidirectional control streams: one called the
encoder stream and the other, the decoder stream.  Each side
opens both, so there are four streams altogether.

The encoder stream carries instructions that modify the dynamic
table.  The header sets are placed into header blocks which are
carried in HQ HEADERS frame on the bidirectional request/response
streams.  The encoder stream does *not* carry header sets.

With regards to framing: the encoder stream does not have framing.
For discussion for the rationale for the lack of encoder stream
framing, see this thread:

  https://www.ietf.org/mail-archive/web/quic/current/msg04229.html

  - Dmitri.