Re: New draft: HTTP Version Translation of the Capsule Protocol

OK, I've written this up in https://github.com/bemasc/capsule-conversion/pull/5/files.  I think this is a good change.  It's not quite as trivial as it sounds (should intermediaries inject the missing capsule-protocol header? what should "Capsule-Protocol: ?0" mean?) but overall I think it will work.

Please review.

--Ben
________________________________
From: David Schinazi <dschinazi.ietf@gmail.com>
Sent: Friday, November 8, 2024 9:30 AM
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: Ben Schwartz <bemasc@meta.com>; ietf-http-wg@w3.org <ietf-http-wg@w3.org>
Subject: Re: New draft: HTTP Version Translation of the Capsule Protocol

That solution works for me, thanks Kazuho. David On Wed, Nov 6, 2024 at 4: 04 PM Kazuho Oku <kazuhooku@ gmail. com> wrote: 2024年11月5日(火) 14: 33 David Schinazi <dschinazi. ietf@ gmail. com>: Hi Ben, Thanks for writing this. The mechanism

That solution works for me, thanks Kazuho.
David

On Wed, Nov 6, 2024 at 4:04 PM Kazuho Oku <kazuhooku@gmail.com<mailto:kazuhooku@gmail.com>> wrote:


2024年11月5日(火) 14:33 David Schinazi <dschinazi.ietf@gmail.com<mailto:dschinazi.ietf@gmail.com>>:
Hi Ben,

Thanks for writing this. The mechanism for conversion is pretty straightforward. I'll note however that it relies on the presence of the `Capsule-Protocol: ?1` header field. Unfortunately we defined RFC 9297 to make that optional. I would have preferred it be mandatory, for exactly the reasons explained in your draft, but that was not the consensus at the time. I think this should be mentioned in your draft, since your mechanism doesn't work when the client doesn't send the optional header.

I wonder if we can solve the issue by slightly changing the phrasing from "if capsule-protocol header exists" to "if the extended protocol is known to use capsule-protocol"?

It is slightly unfortunate that we'd have to have two ways of identifying if the tunnel is transferring capsules, but it'd be beneficial to cover CONNECT-UDP too.


David

On Mon, Nov 4, 2024 at 7:17 PM Ben Schwartz <bemasc@meta.com<mailto:bemasc@meta.com>> wrote:
Hi HTTPBIS

Last year, Kazuho asked us to consider whether an intermediary can translate unrecognized HTTP Upgrade Tokens across HTTP versions [1].  The discussion concluded that this is not possible: an unrecognized Upgrade Token might have an arbitrary interaction with an HTTP extension, and the choice of method in HTTP/1.1 is not defined.

A few days ago, Kazuho and I considered the narrower question of whether this translation is possible within the context of the Capsule Protocol.  We have written a draft that would enable such translations:

https://www.ietf.org/archive/id/draft-kb-capsule-conversion-00.html<https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-kb-capsule-conversion-00.html__;!!Bt8RZUm9aw!4zxNUPSGEhWc3LFVZxSEw-xTrixe57qqYu6V6AXIolV0UW8V8OES1RzjtIVY4w1uYLwf1r1lrQh5tFYNmxRA$>

This draft would enable forward-compatible implementation of Capsule Protocol gateways by committing to some invariants about the Capsule Protocol.

--Ben Schwartz

[1] https://lists.w3.org/Archives/Public/ietf-http-wg/2023OctDec/0005.html<https://urldefense.com/v3/__https://lists.w3.org/Archives/Public/ietf-http-wg/2023OctDec/0005.html__;!!Bt8RZUm9aw!4zxNUPSGEhWc3LFVZxSEw-xTrixe57qqYu6V6AXIolV0UW8V8OES1RzjtIVY4w1uYLwf1r1lrQh5tCbsoWeG$>


--
Kazuho Oku