[quicwg/base-drafts] Alt-Svc and extension equivalence across H2 and H3 (#3101)

Lucas Pardue <notifications@github.com> Wed, 16 October 2019 21:18 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 749EA12080C for <quic-issues@ietfa.amsl.com>; Wed, 16 Oct 2019 14:18:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Status: No, score=-6.596 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_IMAGE_ONLY_28=1.404, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id lZnjBq7m2flK for <quic-issues@ietfa.amsl.com>; Wed, 16 Oct 2019 14:18:29 -0700 (PDT)
Received: from out-17.smtp.github.com (out-17.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8220E1201EF for <quic-issues@ietf.org>; Wed, 16 Oct 2019 14:18:29 -0700 (PDT)
Received: from github-lowworker-d93c4b6.va3-iad.github.net (github-lowworker-d93c4b6.va3-iad.github.net []) by smtp.github.com (Postfix) with ESMTP id D332E6E041F for <quic-issues@ietf.org>; Wed, 16 Oct 2019 14:18:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1571260708; bh=xr8Mmo5ThIIaUOi5jcj7rUu9qcMlvmSAQ42o+f2eotc=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=m4Q58u2EN33o13e3xMkBShCVrMlLa9cZy59aKY3jr1SV56PYABYkcENG3E27g8LvL nKRgRzn6vhUkgWdYKsmknAgOO1cJdehNKyHYozK8YT36xeExhZFPqgAqjx1vxL1tze UuLG8V10ZzjSprlAbsnAPRpTFSvRHkVmk+2eDfVE=
Date: Wed, 16 Oct 2019 14:18:28 -0700
From: Lucas Pardue <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZMA5C2VKV5XF5LOC53WTE3JEVBNHHB4SIQ4Y@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3101@github.com>
Subject: [quicwg/base-drafts] Alt-Svc and extension equivalence across H2 and H3 (#3101)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5da78924c4dcd_6fda3fed66ccd95c109348"; 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/5RayakUxTYyFquqoNk8iqh1EBHk>
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: Wed, 16 Oct 2019 21:18:32 -0000

This is a spin off from a [thread I started on the HTTP WG mailing list](https://lists.w3.org/Archives/Public/ietf-http-wg/2019OctDec/0022.html).

To avoid duplication, the TL;DR is that there could be cases where a H2 connection that is using some type of extension advertises an H3 alternative that is incapable of supporting the connection (most likely due to a configuration mistake). The example I use is WebSockets, which is predicate on extending CONNECT, but it probably applies to all version-specific extensions.

I don't think there is a non-trivial way to prevent such cases. So I propose that we help the ecosystem spot such cases but introducing an error code (this is quite similar to the 421 status code defined in RFC 7838). This error code can be used when closing a stream or a connection - clients can factor this in to their Alt-Svc selection logic, while servers could analyse error codes to spot misconfigurations etc.

Since this problem is more-or-less introduced by HTTP/3, it feels right to define an error code in this document. A separate I-D can specify a similar code for HTTP/2.

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