Re: [quicwg/base-drafts] Replace HTTP_MALFORMED_FRAME error code (#2662)

Kazuho Oku <notifications@github.com> Tue, 02 July 2019 05:55 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 324901200A4 for <quic-issues@ietfa.amsl.com>; Mon, 1 Jul 2019 22:55:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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_HELO_NONE=0.001, SPF_PASS=-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 G2gsy8WhWvF5 for <quic-issues@ietfa.amsl.com>; Mon, 1 Jul 2019 22:54:58 -0700 (PDT)
Received: from out-20.smtp.github.com (out-20.smtp.github.com [192.30.252.203]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17B6E12004D for <quic-issues@ietf.org>; Mon, 1 Jul 2019 22:54:58 -0700 (PDT)
Date: Mon, 01 Jul 2019 22:54:56 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1562046896; bh=7WE5aoVKPHOeewnb+ABM/1+hob8H3exkx7J19SH/gy8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=qB72itT9V/kMBc/HRPnYmOiIZSvHLWlDO4MwtLWapLMhHKNuCBpwbky24+Y1UdfKU aIu0/pvkIhELn+ctAFQkqyBDjXM6oSOBbPUjNZABYfotLUdC4/UbL3ybrXbtx+ruWb QnjQ+QKfyEkxDF/DagKg0bocPuj9rEUYw0HqQXHU=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK33274JDZ4G6MKT4I53FASDBEVBNHHBULDWIQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2662/c507529717@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2662@github.com>
References: <quicwg/base-drafts/pull/2662@github.com>
Subject: Re: [quicwg/base-drafts] Replace HTTP_MALFORMED_FRAME error code (#2662)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d1af1b0d70dc_632b3fa1a10cd960870b4"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/VoqM9aMH84NCsbUivow43CQniDo>
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: Tue, 02 Jul 2019 05:55:01 -0000

@LPardue 
>> I think my preference goes to merging INVALID_PRIORITY with FRAME_ERROR.
> 
> Thanks for the feedback. It's an easy change to make. I'll wait for some supporting or dissenting voices but otherwise will do this.

:+1:

>> Regarding rearranging the numbers, I wonder if it would be possible to split the error codes into two groups: connection-level error codes and stream-level ones. In contrary to HTTP/2, most of the HTTP/3 error code are either a connection-level error code or a stream-level error code, not both.
> 
> This resonates with my earlier analysis. Some of this was captured in #2816. But I think what you are suggesting is a slightly different thing. Can you explain what splitting might look like and how it would help? I think it gets complicated because 1) we may have a proxy that is trying to translate errors between H2 and H3. 2) stream errors can be upgraded to connection errors

IIUC, the following H3 error codes are used at both connection and stream level.

* HTTP_NO_ERROR
* HTTP_GENERAL_PROTOCOL_ERROR
* HTTP_INTERNAL_ERROR

The following codes are used only at connection level, though HTTP_EXCESSIVE_LOAD could be carried at stream level too.
* HTTP_STREAM_CREATION_ERROR
* HTTP_CLOSED_CRITICAL_STREAM
* HTTP_UNEXPECTED_FRAME
* HTTP_FRAME_ERROR
* HTTP_EXCESSIVE_LOAD
* HTTP_WRONG_STREAM
* HTTP_ID_ERROR
* HTTP_INVALID_PRIORITY
* HTTP_SETTINGS_ERROR
* HTTP_MISSING_SETTINGS

The following codes are stream-level errors. While they can be promoted to connection errors, doing so has a risk of resetting other requests inflight. Therefore I'd assume that they would generally be used only at stream-level.
* HTTP_REQUEST_REJECTED
* HTTP_REQUEST_CANCELLED
* HTTP_INCOMPLETE_REQUEST
* HTTP_EARLY_RESPONSE
* HTTP_CONNECT_ERROR
* HTTP_VERSION_FALLBACK

Therefore I thought that it might make sense to explain these three groups differently in the draft.

While I can see the desire to assign codepoints that overlap with HTTP/2, I am not sure if that's a good idea. Not only the error codes are different between H2 and H3, some H2 error codes map to QUIC transport-level errors. Considering the fact that there cannot be a one-to-one mapping, I'm afraid having overlap might backfire against us; it just creates an incentive to pass-through the error codes between different versions of the protocol.

-- 
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/2662#issuecomment-507529717