Re: Upgrade, hmmm...

"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.


---- On Fri, 31 Jul 2020 17:33:48 -0700 Nick Harper <> 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 <> 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?


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

---- On Fri, 31 Jul 2020 16:59:20 -0700 Nick Harper <> wrote ----

On Fri, Jul 31, 2020 at 4:51 PM Eric J Bowman <> 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.


Received on Saturday, 1 August 2020 00:47:06 UTC