Alt-Svc and HTTP Extensions

Lucas Pardue <> Wed, 16 October 2019 19:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8E67B120955 for <>; Wed, 16 Oct 2019 12:03:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.75
X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c3RmacmmWk64 for <>; Wed, 16 Oct 2019 12:03:06 -0700 (PDT)
Received: from ( [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 81B5112093A for <>; Wed, 16 Oct 2019 12:03:05 -0700 (PDT)
Received: from lists by with local (Exim 4.89) (envelope-from <>) id 1iKoWk-0003Fo-5S for; Wed, 16 Oct 2019 19:00:06 +0000
Resent-Date: Wed, 16 Oct 2019 19:00:06 +0000
Resent-Message-Id: <>
Received: from ([2603:400a:ffff:804:801e:34:0:4f]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <>) id 1iKoWg-0000AC-BS for; Wed, 16 Oct 2019 19:00:02 +0000
Received: from ([2607:f8b0:4864:20::92e]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1iKoWe-0006Qx-Ns for; Wed, 16 Oct 2019 19:00:02 +0000
Received: by with SMTP id m21so7559844ual.13 for <>; Wed, 16 Oct 2019 11:59:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=QsgKx3MJ0mwRvG23lj2PEkoc+e6ku3Zgj/paFgxXj7I=; b=N3wdkitjqTJTEhrON4ejx4hGbrDjjAO5+5ZSGskm3Pv/CuciHykugmGmcR0txz9Wrq ylKe56J5g/8Z1vYOpnmT93iZpvvNNK3WF2Yt8hWW/HiLfrz9lQ/PEfJ9QdYe4lESthJL k7r/T0AwUTmJ8J/nDvMjEDbBGvdf1qqhxPv1XHXP42W6Jc1IsxoRensp2QB5/ONmLRU/ U1gcOjKJPjlVrlXCYKyAstqSue8D2sPSKQjSgUNUrZZ4GglyVyUd8XmhFuwKFfFD8d2e JM+NahDYjuqmzbjcY0AM8dVAPjxTRsvqim77MeGugRRFAHTr4QJWIY4MrYFCnhAVjSZE zmLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=QsgKx3MJ0mwRvG23lj2PEkoc+e6ku3Zgj/paFgxXj7I=; b=ISmscYPhVfpMzeYgqO3TV2urusdH2PE2aLdL6h+O4TR5+NHisGb82yMU/EQ7rmxOz3 8x2ESBh5EI7c4PC2esHmMShBF/WZZkZCtqrB61hFXJvOE/89NBHRTblHtEzYNweg0ZSH b2OVt3+LG68U/ZRXzEYsUGtD9dDMejy6zVpmOpNAdPauMFsYz3cPf/v+4pGcRIpK5Aul bRbyxAuyAuiXPgsuQReq/sScT1zMAnjI2bnvmsxknuBaMmGJfb8STabrqepkyfSN/XXg 0Nt0EFSdazc/YijOCKMTrUQLRUEgR46UV9oBIsaNOPoAMYsWIVCMgdHqo7uKDDDhxwIQ YwOQ==
X-Gm-Message-State: APjAAAWXIbGSpexB/n5CKrNKs8FB3PIXYY7MGaqjSiggwn8mK5GYRLl2 4dk1uqedjeTwKmogE0TmlpPLGH4kmwRJ8NN7t9Rh2Wch
X-Google-Smtp-Source: APXvYqzf7W2Ot8sNahDNPlVY6c2jxi3snWvBGFuXb5wq/WTWDgZld/nxnMmY7uY3wV0apmUnVokUjJcdjLMoY08IM3o=
X-Received: by 2002:a9f:3fcb:: with SMTP id m11mr1377572uaj.69.1571252398744; Wed, 16 Oct 2019 11:59:58 -0700 (PDT)
MIME-Version: 1.0
From: Lucas Pardue <>
Date: Wed, 16 Oct 2019 19:59:47 +0100
Message-ID: <>
To: HTTP Working Group <>
Content-Type: multipart/alternative; boundary="0000000000001469d005950bb516"
Received-SPF: pass client-ip=2607:f8b0:4864:20::92e;;
X-W3C-Hub-Spam-Status: No, score=-3.8
X-W3C-Scan-Sig: 1iKoWe-0006Qx-Ns dc9a0c22a1d4a9f82ca976ccea1b7535
Subject: Alt-Svc and HTTP Extensions
Archived-At: <>
X-Mailing-List: <> archive/latest/37058
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

RFC 7838 frames a lot of discussion in terms of resource fetching, which is
supplied equivalently  by the core definitions of HTTP/2 and HTTP/3.
Therefore failure of an Alternative is discussed in terms of connection
errors or 421 (Misdirected Request) HTTP Status Code. But I'm starting to
wonder what expectations are for some classes of HTTP extension.

Lets assume a world where HTTP/2 and HTTP/3 co-exist but development and
deployment of extensions progresses at different rates. For example, right
now we may have HTTP/2 servers that support WebSocket (RFC 8441) but few
HTTP/3 servers that offer a similar extension (both because it is not
formally defined, and because it is not deployed on a fully authoritative

A client that is happily using HTTP/2 WebSockets may see an Alt-Svc for
HTTP/3 and eventually decide to switch, only to find that it cannot do
HTTP/3 WebSockets. It could discover this early, because in this case the
extension is negotiated using SETTINGS_ENABLE_CONNECT. Howver, not all
extension require such a negotiation.

So the question is, was it correct or fair for the HTTP/2 server to
advertise the alternative that cannot satisfy the exact same desired
properties of the active connection? It seems like a class of error similar
to Misdirect Request, caused by accidental advertisement due to poor
coordination. However, extensions may not be bound to request/response, so
perhaps there might be some benefit in defining a new error code that
allows an endpoint to reset streams or close connections.