Re: [quicwg/base-drafts] Transport error codes would be smaller and more consistent as a varint (#2672)

Kazuho Oku <> Thu, 09 May 2019 00:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2FD6E12025D for <>; Wed, 8 May 2019 17:39:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.392
X-Spam-Status: No, score=-6.392 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W8Mg65ZCe8Jc for <>; Wed, 8 May 2019 17:39:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4F45E120220 for <>; Wed, 8 May 2019 17:39:04 -0700 (PDT)
Date: Wed, 08 May 2019 17:39:03 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1557362343; bh=bG4BASuv+oxhecPg0HK94QsFjvI4MNoRRezTsZubnAE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=kJtQ4jIaQVy6N6WGqOcyxsYH/f0RoZzN/d/7P9xHV6RQCJZ2CZ65rTtdUgNdVifxY /a0cJdsMQ+DjhvbjqpoASpjpH0lUbtlCDYjMbVcar+qzccHaZsTt0TZe0wZfNhIjGE +gFeFrLPpnK3xia410MfqEpnv6kNA9k7QJkAw6cM=
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2672/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Transport error codes would be smaller and more consistent as a varint (#2672)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cd376a75c20f_6ba23ff9a70cd95c135583"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 May 2019 00:39:19 -0000

I also think that varint is OK. It gives application protocols to use up to 62-bit space for error codes rather than enforcing them to use 16-bit space. The downside is that the CONNECTION_CLOSE frame could become one byte bigger, but I do not think that is a real cost.

Re HTTP_MALFORMED_FRAME, my preference goes to either a) recommend endpoints expressing the offending frame type in the reason phrase, or b) change the definition of application-close frame (i.e. CONNECTION_CLOSE with type=0x1d) to carry a blob, and define in the HTTP/3 spec. that the blob would be a tuple of error-code (varint), offending-frame-type (varint), and a reason phrase.

My view is that 2^60 is a dirty hack. It works, but I'd argue that it is a sign the HTTP draft doing something unexpected by the transport design. Therefore, I'm arguing to do what is expected by the transport, or change the design of the transport to meet the requirement of HTTP.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: