Re: Upgrade, hmmm...

Eric J Bowman <mellowmutt@zoho.com> Sat, 01 August 2020 00:47 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 185223A0E05 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 31 Jul 2020 17:47:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.018
X-Spam-Level:
X-Spam-Status: No, score=-3.018 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.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (768-bit key) header.from=mellowmutt@zoho.com header.d=zoho.com; dkim=pass (1024-bit key) header.d=zoho.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 B55Y9Mr6a0yv for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 31 Jul 2020 17:47:22 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (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 400BA3A0E04 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 31 Jul 2020 17:47:22 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1k1fg3-0000zr-Vj for ietf-http-wg-dist@listhub.w3.org; Sat, 01 Aug 2020 00:47:08 +0000
Resent-Date: Sat, 01 Aug 2020 00:47:07 +0000
Resent-Message-Id: <E1k1fg3-0000zr-Vj@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <mellowmutt@zoho.com>) id 1k1fg2-0000yl-Mr for ietf-http-wg@listhub.w3.org; Sat, 01 Aug 2020 00:47:06 +0000
Received: from sender4-pp-o93.zoho.com ([136.143.188.93]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <mellowmutt@zoho.com>) id 1k1fg1-0006CA-1E for ietf-http-wg@w3.org; Sat, 01 Aug 2020 00:47:06 +0000
ARC-Seal: i=1; a=rsa-sha256; t=1596242808; cv=none; d=zohomail.com; s=zohoarc; b=OIhSHq58kaXpoG9QRK7/7wh6NXg4fgLXlI7BAsaVOoyXMvu9zPP4fNgWMF2OJHtSoDpCaBrRvquPuNVPG++isQtGyN31eoXD4OVgsccQAEbdFujZPdaEUuu5MFieSWp4A+0fJmm2nc4uBNQ17GpH6bKjr5iuGQQQyQsQK9rZvtg=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1596242808; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=vnw1ogQQLsikkdcuigSkr2eZEpgM2KJ4rb28EK5Wybk=; b=ejhbnErIPQHo6Zb+BL1ZEU4n960drpSYm+T+CWywVMHetRUqIJKA0PHXfUwVTxfle50wZlLJZCVJBcyEpm3BOd0Mzxsl5xXSwFDEZrErE/QeVA5g9GLwdLLkqEYsl1daEwi45xplauB8WAqepFg8idqPNGAQiKy2+HV+RahVxPs=
ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=zoho.com; spf=pass smtp.mailfrom=mellowmutt@zoho.com; dmarc=pass header.from=<mellowmutt@zoho.com> header.from=<mellowmutt@zoho.com>
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=date:from:to:cc:message-id:in-reply-to:references:subject:mime-version:content-type:user-agent; b=tsGebudv0iVF3A5xoIjTcgffX7k8zCDzEtq2K+un66YsEd9juVFxe/Ck0xmnkKmsUnAhW9yGLUAy gF6yoIAMf9h9v220z6tS/ZwI5Xu1ZMfO1VEkmbg9y7SQkTyq7uAl
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1596242808; s=zm2020; d=zoho.com; i=mellowmutt@zoho.com; h=Date:From:To:Cc:Message-Id:In-Reply-To:References:Subject:MIME-Version:Content-Type; bh=vnw1ogQQLsikkdcuigSkr2eZEpgM2KJ4rb28EK5Wybk=; b=LugcZmUM3Lcyn6yt8uPZlF/jMrcVk53SQYL6XWJzrekLxhKGUE84QGPrgYcFcQH8 tVzxJOVIpb9lpHTZ2jkogG5YZn8IWWIh3s80JMdOWNviF2xBJOwySijJR5i01CXivcJ zYwcn6KHDYbEuXwaXYocmU9MYCaEaKol9XyTeGSg=
Received: from mail.zoho.com by mx.zohomail.com with SMTP id 15962428063291012.0552297889665; Fri, 31 Jul 2020 17:46:46 -0700 (PDT)
Received: from [65.117.211.248] by mail.zoho.com with HTTP;Fri, 31 Jul 2020 17:46:46 -0700 (PDT)
Date: Fri, 31 Jul 2020 17:46:46 -0700
From: Eric J Bowman <mellowmutt@zoho.com>
To: "Nick Harper" <nharper@google.com>
Cc: "Ietf Http Wg" <ietf-http-wg@w3.org>
Message-Id: <173a77c4621.f98f8ddd55587.1042202071606716599@zoho.com>
In-Reply-To: <CACdeXiLFhJSUwS9bSfbFtuoKdw+Pb=hLO6Z2t71b_pf66cNPPA@mail.gmail.com>
References: <173a745b6b7.e84f51cd55203.5714415482168204840@zoho.com> <CACdeXiKXn_RDkK5OqxOhxmEAXDj80CgqN_cYCugVL5LHembJjg@mail.gmail.com> <173a76def4b.c5d7089c55482.3290597986042746664@zoho.com> <CACdeXiLFhJSUwS9bSfbFtuoKdw+Pb=hLO6Z2t71b_pf66cNPPA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_159627_1659673431.1596242806306"
Importance: Medium
User-Agent: Zoho Mail
X-Mailer: Zoho Mail
Received-SPF: pass client-ip=136.143.188.93; envelope-from=mellowmutt@zoho.com; helo=sender4-pp-o93.zoho.com
X-W3C-Hub-Spam-Status: No, score=-4.1
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_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 1k1fg1-0006CA-1E 2fe7d37cc4688fa5ea262c7b0dcce092
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Upgrade, hmmm...
Archived-At: <https://www.w3.org/mid/173a77c4621.f98f8ddd55587.1042202071606716599@zoho.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37920
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>

"This isn't just my interpretation of Upgrade, it is how it is defined in RFC 7230, section 6.7."



I know! I'm sorry I've been away for a long time, I certainly had every chance to chime in on that RFC bitd. But it says right in that RFC that it's intended to avoid an extra round trip. What if I don't care?



Why I came out of hiding to suggest maybe a "Protocol" header without those requirements, at the expense of a round trip, because since RFC 7230, we have HTTP/2 and HTTP/3. Easy enough to code my way, but not standardized, my way also allows "Downgrade" to cleartext, requiring a new connection.


-Eric

---- On Fri, 31 Jul 2020 17:33:48 -0700 Nick Harper <mailto:nharper@google.com> wrote ----


This isn't just my interpretation of Upgrade, it is how it is defined in RFC 7230, section 6.7.

If you want to say "I also support these other protocols", check out Alt-Svc (RFC 7838).



On Fri, Jul 31, 2020 at 5:31 PM Eric J Bowman <mailto:mellowmutt@zoho.com> wrote:

Not how current browsers work, no. But, a client asking for that upgrade and getting an affirmative response via TCP, can feel free to repeat the request via UDP. At the cost of a round-trip. I'm taking under consideration your interpretation of Upgrade as being meant for the same connection, my way would be a different connection, you're right. What's the downside?



-Eric


(sorry for the double-post if I forgot to reply all, oops)

---- On Fri, 31 Jul 2020 16:59:20 -0700 Nick Harper <mailto:nharper@google.com> wrote ----





On Fri, Jul 31, 2020 at 4:51 PM Eric J Bowman <mailto:mellowmutt@zoho.com> wrote:

Please refer me to previous discussions about why h2 and h2c, but no h1, h1c, or h3.



I'm coding a webserver from scratch, with the goal of serving an index.html file and its ancillaries, over any of HTTP/1.1, HTTP/2, HTTP/3, FTP, WAKA (if Roy ever publishes it), or "ERIC" because I have my own ideas. Encrypted or not (I realize "not" isn't an option with HTTP/3). So the main loop is protocol-negotiation hell worse than any conneg/langneg I've ever coded.



If I'm hosting multiple websites on my service, I might want to default to h2, at this time. But if one of those client websites is a law firm, they don't care about serving legal definitions over "h1c" to incarcerated clients, who aren't allowed to use encryption unless it's attorney-client privileged communication. So, how does a gateway at the prison wall connect using h2 but request "Downgrade: h1c"? Or maybe there could be a "Protocol" header with a weighted list (lol).



(Taking a presentation I watched on YouTube by PHK, to heart -- some sovereign states disallow encryption, and heck, America's own FBI wants to kill it. But I agree it's important to be able to downgrade to cleartext.)



Or, why can't an h2c connection request Upgrade: h3? Coding my webserver to shift those gears, turns out to be trivial, all things considered at this point. So, why are only h2/h2c standardized as Upgrade tokens?






The Upgrade header is used to suggest switching protocols on the *same* connection. Given that an h2 (or h2c) connection runs on TCP and HTTP/3 runs on UDP, there's no way to upgrade the existing connection to HTTP/3.





-Eric