Subject: QPACK: how to handle bogus data on encoder or decoder stream

From: Bence Béky <[email-masked]>
Date: Fri, 17 Aug 2018 11:13:57 -0400

Hi,

It is possible for a peer to receive invalid data on the encoder or
decoder stream.  For example, on the encoder stream, a Duplicate
instruction might address an already evicted entry.  Or on the decoder
stream, a Table State Synchronize might contain an Insert Count
exceeding the total number of applicable inserts and duplications, or
the Header Acknowledgement might contain a Stream ID for which there
are no unacknowledged header blocks.  As far as I can tell, the spec
currently gives no direction on what should happen in such cases.

I propose that these should be treated as connection errors.

HTTP_QPACK_DECOMPRESSION_FAILED seems like a relevant error code, but
it does not really match any of these cases (strictly speaking, these
errors do not happen during decompression), especially incorrect data
on the decoder stream (because it is the encoder, not the decoder,
that detects the error).  Should there be one error code covering all
these cases, something like HTTP_QPACK_ERROR?  Or should there be
multiple, like HTTP_QPACK_DECOMPRESSION_FAILED for errors on HEADERS
and PUSH_PROMISE frames, and self-explanatory
HTTP_QPACK_ENCODER_STREAM_ERROR and HTTP_QPACK_DECODER_STREAM_ERROR?

Bence

---

From: Alan Frindell <[email-masked]>
Date: Fri, 17 Aug 2018 23:14:43 +0000

I believe the intent is for those errors to be connection errors.  As for error codes, I know there's been some back and forth in QUIC about whether more error codes are really useful, but in this case I think it is useful to distinguish control stream errors from decoding errors.  I opened issue #1683 to track.

-Alan

On 8/17/18, 8:14 AM, "QUIC on behalf of Bence Béky" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    
    
    Bence