Alt-Svc and HTTP Extensions
Lucas Pardue <lucaspardue.24.7@gmail.com> Wed, 16 October 2019 19:03 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E67B120955 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 16 Oct 2019 12:03:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.75
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 c3RmacmmWk64 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 16 Oct 2019 12:03:06 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [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 ietfa.amsl.com (Postfix) with ESMTPS id 81B5112093A for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 16 Oct 2019 12:03:05 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1iKoWk-0003Fo-5S for ietf-http-wg-dist@listhub.w3.org; Wed, 16 Oct 2019 19:00:06 +0000
Resent-Date: Wed, 16 Oct 2019 19:00:06 +0000
Resent-Message-Id: <E1iKoWk-0003Fo-5S@frink.w3.org>
Received: from mimas.w3.org ([2603:400a:ffff:804:801e:34:0:4f]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <lucaspardue.24.7@gmail.com>) id 1iKoWg-0000AC-BS for ietf-http-wg@listhub.w3.org; Wed, 16 Oct 2019 19:00:02 +0000
Received: from mail-ua1-x92e.google.com ([2607:f8b0:4864:20::92e]) by mimas.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <lucaspardue.24.7@gmail.com>) id 1iKoWe-0006Qx-Ns for ietf-http-wg@w3.org; Wed, 16 Oct 2019 19:00:02 +0000
Received: by mail-ua1-x92e.google.com with SMTP id m21so7559844ual.13 for <ietf-http-wg@w3.org>; Wed, 16 Oct 2019 11:59:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 <lucaspardue.24.7@gmail.com>
Date: Wed, 16 Oct 2019 19:59:47 +0100
Message-ID: <CALGR9oYaMWKbmRzP7=F8pj999k6L42M2Nxp+1r2JFWLXfeLh9w@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="0000000000001469d005950bb516"
Received-SPF: pass client-ip=2607:f8b0:4864:20::92e; envelope-from=lucaspardue.24.7@gmail.com; helo=mail-ua1-x92e.google.com
X-W3C-Hub-Spam-Status: No, score=-3.8
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1iKoWe-0006Qx-Ns dc9a0c22a1d4a9f82ca976ccea1b7535
X-Original-To: ietf-http-wg@w3.org
Subject: Alt-Svc and HTTP Extensions
Archived-At: <https://www.w3.org/mid/CALGR9oYaMWKbmRzP7=F8pj999k6L42M2Nxp+1r2JFWLXfeLh9w@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37058
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=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 alternative). 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. Lucas
- Alt-Svc and HTTP Extensions Lucas Pardue
- Re: Alt-Svc and HTTP Extensions Patrick McManus