Re: [quicwg/base-drafts] Define three QPACK error types, refine error handling. (#1726)

afrind <notifications@github.com> Thu, 06 September 2018 20:26 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AACD5130F1F for <quic-issues@ietfa.amsl.com>; Thu, 6 Sep 2018 13:26:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.009
X-Spam-Level:
X-Spam-Status: No, score=-8.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fUcCMby5_5y for <quic-issues@ietfa.amsl.com>; Thu, 6 Sep 2018 13:26:33 -0700 (PDT)
Received: from out-14.smtp.github.com (out-14.smtp.github.com [192.30.254.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02535130EDB for <quic-issues@ietf.org>; Thu, 6 Sep 2018 13:26:32 -0700 (PDT)
Date: Thu, 06 Sep 2018 13:26:32 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1536265592; bh=NyftgPzjEdtvLb3AUzDLUhI2Hw2FlQWxvCn4iN86RPc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=HNUTSj4/1XgEuPRLst37DSVfbUWLauY6oTRkOvP8IY3iDo4uFRm7svcuE+Lmdubv4 Z7l+tfbjukwaMHSrHAIYe2xRXSQZYq+jYclXd2AAbETqWv4rGMnJHAnDh18WY2QO+x tGg9hcHtYpxQdE8Na8EuRgz3sP148yGCRWA/1eyo=
From: afrind <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abb8814733aba5c5e379077aa16b8aa22341d5bfda92cf0000000117a94f7892a169ce1553053a@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/1726/review/153097791@github.com>
In-Reply-To: <quicwg/base-drafts/pull/1726@github.com>
References: <quicwg/base-drafts/pull/1726@github.com>
Subject: Re: [quicwg/base-drafts] Define three QPACK error types, refine error handling. (#1726)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b918d7855b61_378a3fc6f94d45b82431d"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: afrind
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/LbdAx14LEK5G2ZnDhUMX5KcqIok>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Sep 2018 20:26:38 -0000

afrind commented on this pull request.

Thanks for putting this up.

> @@ -120,6 +120,12 @@ which has a fixed index over time.  Its entries are defined in Appendix A of
 {{!RFC7541}}. Note that because HPACK did not use zero-based references, there
 is no value at index zero of the static table.
 
+A decoder that encounters an invalid static table index on a request stream or
+push stream MUST treat this as an error of type

I think it would be more clear to use stream error here, and if an implementation wants to make it a connection error they can.

> @@ -120,6 +120,12 @@ which has a fixed index over time.  Its entries are defined in Appendix A of
 {{!RFC7541}}. Note that because HPACK did not use zero-based references, there
 is no value at index zero of the static table.
 
+A decoder that encounters an invalid static table index on a request stream or
+push stream MUST treat this as an error of type

Would it be better to have this text under the Absolute and Relative Indexing section, rather than here?

> @@ -248,11 +254,14 @@ d = count of entries dropped
 ~~~~~
 {: title="Example Dynamic Table Indexing - Post-Base Index on Request Stream"}
 
-If the decoder encounters a reference to an entry which has already been dropped
-from the table or which is greater than the declared Largest Reference (see
-{{absolute-index}}), this MUST be treated as a stream error of type
-`HTTP_QPACK_DECOMPRESSION_FAILED` error code.  If this reference occurs on the
-encoder stream, this MUST be treated as a session error.
+If the decoder encounters a reference on a request or push stream to a dynamic
+table entry which has already been dropped or which has an absolute index
+greater than the declared Largest Reference (see {{absolute-index}}), this MUST
+be treated as an error of type `HTTP_QPACK_DECOMPRESSION_FAILED`.
+
+If the decoder encounters a reference on the encoder stream to a dynamic table
+entry which has already been dropped or which has not yet been inserted, this

This was already a problem, but there's not correct agreement in these sentences.  '...if the decoder...this must be treated' should be  '...if the decoder... it must treat'.  If you don't feel like mucking with it we can clean it up later.

> @@ -248,11 +254,14 @@ d = count of entries dropped
 ~~~~~
 {: title="Example Dynamic Table Indexing - Post-Base Index on Request Stream"}
 
-If the decoder encounters a reference to an entry which has already been dropped
-from the table or which is greater than the declared Largest Reference (see
-{{absolute-index}}), this MUST be treated as a stream error of type
-`HTTP_QPACK_DECOMPRESSION_FAILED` error code.  If this reference occurs on the
-encoder stream, this MUST be treated as a session error.
+If the decoder encounters a reference on a request or push stream to a dynamic
+table entry which has already been dropped or which has an absolute index
+greater than the declared Largest Reference (see {{absolute-index}}), this MUST
+be treated as an error of type `HTTP_QPACK_DECOMPRESSION_FAILED`.
+
+If the decoder encounters a reference on the encoder stream to a dynamic table
+entry which has already been dropped or which has not yet been inserted, this

Also, I don't think you can make a reference on the encoder stream to a header that has not yet been inserted.  Index 0 is the most recently inserted entry.

> @@ -270,8 +279,8 @@ immediately. A stream becomes unblocked when the greatest absolute index in the
 dynamic table becomes greater than or equal to the Largest Reference for all
 header blocks the decoder has started reading from the stream.  If a decoder
 encounters a header block where the actual largest reference is not equal to the
-Largest Reference declared in the prefix, it MAY treat this as a stream error of
-type HTTP_QPACK_DECOMPRESSION_FAILED.
+Largest Reference declared in the prefix, it MUST treat this as an error

See the discussion of MUST vs. MAY for this case in https://github.com/quicwg/base-drafts/issues/1404.

I was for MUST here previously.  I think the argument against it was that it's kind of annoying to check it potentially, and some organizations require all MUSTs to be implemented or have a 'really good reason' (TM).

> @@ -291,7 +300,7 @@ An encoder MUST limit the number of streams which could become blocked to the
 value of SETTINGS_QPACK_BLOCKED_STREAMS at all times. Note that the decoder
 might not actually become blocked on every stream which risks becoming blocked.
 If the decoder encounters more blocked streams than it promised to support, it
-SHOULD treat this as a stream error of type HTTP_QPACK_DECOMPRESSION_FAILED.
+MUST treat this as an error of type HTTP_QPACK_DECOMPRESSION_FAILED.

I'm inclined to agree with you. Will let the MAY/SHOULD side weigh in.

> @@ -602,6 +609,17 @@ blocks within a stream have been fully processed.
 ~~~~~~~~~~
 {:#fig-header-ack title="Header Acknowledgement"}
 
+The same Stream ID can be identified multiple times, as multiple header blocks
+can be sent on a single stream in the case of intermediate responses, trailers,
+and pushed requests.  Since header frames on each stream are received and
+processed in order, this gives the encoder precise feedback on which header
+blocks within a stream have been fully processed.
+
+If an encoder receives a Header Acknowledgement instruction referring to a
+stream on which every header block with non-zero Largest Reference has already

Does 'with *a* non-zero Largest Reference' sound better?

>  QPACK which prevent the stream or connection from continuing:
 
-HTTP_QPACK_DECOMPRESSION_FAILED (0x06):
-: QPACK failed to decompress a frame and cannot continue.
+HTTP_QPACK_DECOMPRESSION_FAILED (TBD):
+: The decoder failed to interpret an instruction on a request or push stream and
+  is not able to continue decoding that header block.  This situation MAY be

I think this is already the intent, but I don't think it hurts to spell it out here.  Also, maybe we can get rid of the word situation in all three error descriptions?

>  QPACK which prevent the stream or connection from continuing:
 
-HTTP_QPACK_DECOMPRESSION_FAILED (0x06):
-: QPACK failed to decompress a frame and cannot continue.
+HTTP_QPACK_DECOMPRESSION_FAILED (TBD):
+: The decoder failed to interpret an instruction on a request or push stream and
+  is not able to continue decoding that header block.  This situation MAY be

Did you mean to remove the error code value?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1726#pullrequestreview-153097791