connect-tcp: should capsules be negotiated or always on?

httpwg / http-extensions

HTTP Extensions in progress

445 stars 146 forks source link

connect-tcp: should capsules be negotiated or always on? #2922

Closed DavidSchinazi closed 3 weeks ago

DavidSchinazi commented 3 weeks ago

We started this discussion in the comments of #2921 but it deserves its own issue. Now that #2921 has landed, capsule support is mandatory for servers but clients can decide whether or not to use it by sending the Capsule-Protocol = ?1 header. Another way forward would be to just say that connect-tcp always uses capsules. Some reasons why:

it simplifies server implementations
it simplifies client implementations that want capsules
it would be consistent with every other :protocol that uses capsules
it avoids reusing Capsule-Protocol to mean something different from what was intended in RFC 9297

Since I don't see any real-world reason to use connect-tcp without capsules, this sounds like the best path forward to me

cc @bemasc @LPardue @tfpauly

LPardue commented 3 weeks ago

I'm sympathetic to the argument that there may be cases where someone wants templates tcp without the overhead of capsules. So how about we move the capsule negotiation to the upgrade token? I.e. one token if you want capsules, another if you don't. Then it makes the use of capsule-protocol header more consistent with how it's already used in other connect-foo docs.

DavidSchinazi commented 3 weeks ago

That's a good compromise. That allows me to only implement the upgrade token that enables capsules and not have to deal with the complexity of negotiation.

Another option would be to say that if capsule_length == UINT64_MAX then the capsule extends to the end of the stream. That works because stream offsets only go to UINT64_MAX so that length cannot ever be valid. It's a shame we didn't do that in 9297 though

kazuho commented 3 weeks ago

Another option would be to say that if capsule_length == UINT64_MAX then the capsule extends to the end of the stream.

I think this approach works for the sender to indicate its disinterest to use capsules. But it does not allow the receiver to refuse use of capsules by the sender.

By saying using connect-tcp without capsules, I think we are referring to endpoints that do not want to implement capsule support at neither send-side or receive-side.

Assuming that is the case, I think using different upgrade token is the way to go, if somebody asks for connect-tcp without capsules.

bemasc commented 3 weeks ago

OK, PR up: https://github.com/httpwg/http-extensions/pull/2926. Please review.