IETF Logo Mail Archive

Re: [quicwg/base-drafts] Replace HTTP_MALFORMED_FRAME for something simpler (#2551)

Lucas Pardue <notifications@github.com> Sat, 18 May 2019 11:09 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 2C27D120075 for <quic-issues@ietfa.amsl.com>; Sat, 18 May 2019 04:09:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.392
X-Spam-Level:
X-Spam-Status: No, score=-1.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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=no 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 bFrtfkc_sbiM for <quic-issues@ietfa.amsl.com>; Sat, 18 May 2019 04:09:54 -0700 (PDT)
Received: from out-24.smtp.github.com (out-24.smtp.github.com [192.30.252.207]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09286120052 for <quic-issues@ietf.org>; Sat, 18 May 2019 04:09:54 -0700 (PDT)
Date: Sat, 18 May 2019 04:09:53 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1558177793; bh=EzTRy2xHuybN122lNEcomKOH2e90Evqglijq1oZx8Jc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=dSl5bdbBCdGHibFoa2nWcFhZfszSDqU3YklrulXTAXu46AZh+K1kMxTGwo1UUpuTu Na/l5Y3q7RHsgLR74XAlgSRmBpvReIXCENBIophjbgC6qpFI3HzCjs0zwn2QA/+j9c UnjRTrWe4t4o5sbpMtBvrNan/vY8tAKgiMbfAaP8=
From: Lucas Pardue <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5XWGKHV23OPNKULBV25UNIDEVBNHHBSVI6GU@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2551/493668731@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2551@github.com>
References: <quicwg/base-drafts/issues/2551@github.com>
Subject: Re: [quicwg/base-drafts] Replace HTTP_MALFORMED_FRAME for something simpler (#2551)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cdfe801246a2_645e3fba6c6cd96c507ef"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: LPardue
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/SR7PGpW2JOjw7irbtLTkcDxQMrE>
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: Sat, 18 May 2019 11:09:55 -0000

Quoting myself:

> Another wrinke is: What should an endpoint do if it receives an error that references an unknown frame type? An endpoint MUST ignore unknown types, and we have these in the form of grease frame types with values that are included in the error code space.

Endpoint X receives a GREASE frame and for whatever reason decides to issue a stream error with a HTTP_MALFORMED_FRAME code that covers GREASE. Endpoint Y receives the error code, and takes this as a signal that X didn't follow the rule to ignore the frame. So it sends a connection error back?

This is an edge case yes, but I think it is another argument against declaring a very large codepoint space that is mostly useless in practice. 

-- 
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/issues/2551#issuecomment-493668731

v2.28.0 | Report a Bug | By Email | System Status