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. David On Mon, Nov 4, 2024 at 7:17 PM Ben Schwartz <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 > > 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 >
Received on Tuesday, 5 November 2024 14:33:14 UTC