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

2024年11月5日(火) 14:33 David Schinazi <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> 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
>>
>

-- 
Kazuho Oku