- From: Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com>
- Date: Sat, 27 Jan 2024 01:39:11 -0500
- To: Ben Schwartz <bemasc@meta.com>
- Cc: Tommy Pauly <tpauly@apple.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Thu, Jan 25, 2024 at 03:59:46PM +0000, Ben Schwartz wrote: > Hi Glenn, > > I agree, the standardization status of "Upgrade: HTTP/2.0" seems to be ambiguous. In this draft version, I attempted to address it for completeness without implying that it actually exists. I'm happy to delete or rework that section as needed. > > --Ben https://datatracker.ietf.org/doc/draft-schwartz-httpbis-optimistic-upgrade/ Section 5.1. "HTTP" ... > A version number of "2.0" corresponds to HTTP/2. Every HTTP/2 > connection begins with a Client Connection Preface (Section 3.4 of > [RFC9113]) that was selected to ensure that a compliant HTTP/1.1 > server will not process further data on this connection. This avoids > security issues if an "HTTP/2.0" Upgrade Token is used > optimistically. I propose that this paragraph be removed or replaced, since an RFC for Upgrade: HTTP/2.0 is an Expired Internet-Draft [1] Instead of the Upgrade: HTTP/2.0 token, the paragraph could instead reference HTTP/2 prior knowledge, e.g.: "Every HTTP/2 connection begins with a Client Connection Preface (Section 3.4 of [RFC9113]) that was selected to ensure that a compliant HTTP/1.1 server will not process further data on this connection as HTTP/1.1 request(s). This avoids security issues if a client sends the HTTP/2 Connection Preface over a clear-text connection to an HTTP/2 server supporting HTTP/2 prior knowledge (Section 3.3 of [RFC9113])." Cheers, Glenn [1] HTTP 2.0 Negotiation draft-montenegro-httpbis-http2-negotiation-01 https://datatracker.ietf.org/doc/html/draft-montenegro-httpbis-http2-negotiation > ________________________________ > From: Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com> > Sent: Thursday, January 25, 2024 1:04 AM > To: Tommy Pauly <tpauly@apple.com> > Cc: HTTP Working Group <ietf-http-wg@w3.org> > Subject: Re: Adoption call for draft-schwartz-httpbis-optimistic-upgrade > > !-------------------------------------------------------------------| > This Message Is From an External Sender > > |-------------------------------------------------------------------! > > On Tue, Jan 23, 2024 at 09:41:39AM -0800, Tommy Pauly wrote: > > Hello HTTP, > > > > This email starts a working group adoption call for "Security Considerations for Optimistic Use of HTTP Upgradeā, draft-schwartz-httpbis-optimistic-upgrade. Notably, this updates RFC 9298 (connect-udp, which was produced by the MASQUE WG) on how to handle HTTP Upgrade, including to disallow optimistic data sending for HTTP/1.1. > > > > The document can be found here: > > > > https://datatracker.ietf.org/doc/draft-schwartz-httpbis-optimistic-upgrade/ > > https://www.ietf.org/archive/id/draft-schwartz-httpbis-optimistic-upgrade-00.html > > > > This adoption call will last for 3 weeks, until Tuesday, February 13. Please reply to this email with your reviews and comments, and whether or not you think HTTPBIS should adopt this draft. > > The draft section 5.1 "HTTP" mentions token "HTTP/2.0". > > Is there a published RFC -- not an expired draft -- which describes > handling of Upgrade: HTTP/2.0? Are there any known implementations > (client or server) which support HTTP/1.1 Upgrade: HTTP/2.0? > > There is a now-obsoleted h2c token for HTTP/1.1 upgrade of clear-text > (non-encrypted) HTTP/1.1 via HTTP/1.1 Upgrade: h2c, but h2c is > different from Upgrade: HTTP/2.0 > > Thank you for pointers to Upgrade: HTTP/2.0 specifications, besides a > brief mention of 'e.g., "2.0"' in RFC 9110 Section 18.10 > Upgrade Token Registration. > > Cheers, Glenn >
Received on Saturday, 27 January 2024 06:39:30 UTC