Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[connect-tcp] Move capsule negotiation into the Upgrade Token #2926

Merged
merged 2 commits into from
Oct 21, 2024
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions draft-ietf-httpbis-connect-tcp.md
Original file line number Diff line number Diff line change
Expand Up @@ -145,13 +145,13 @@ Authentication to a templated TCP proxy normally uses ordinary HTTP authenticati

Clients SHOULD assume that all proxy resources generated by a single template share a protection space (i.e., a realm) ({{?RFC9110, Section 11.5}}). For many authentication schemes, this will allow the client to avoid waiting for a "401 (Unauthorized)" response before each new connection through the proxy.

### Use of the Capsule Protocol {#capsule-protocol}
## Use of the Capsule Protocol {#capsule-protocol}

In this specification, support for the Capsule Protocol {{?RFC9297}} is OPTIONAL for clients. Clients MAY request use of the Capsule Protocol by including a "Capsule-Protocol: ?1" header field in the request.
When using the "connect-tcp" Upgrade Token, templated TCP proxies do not use the Capsule Protocol {{!RFC9297}}. Clients MAY request use of the Capsule Protocol by offering the Upgrade Token "connect-tcp-capsule" instead. When offering or accepting the "connect-tcp-capsule" Upgrade Token, clients and servers SHOULD including a "Capsule-Protocol: ?1" header to facilitate processing by intermediaries.

Server support for the Capsule Protocol is REQUIRED. Servers MUST confirm use of the Capsule Protocol by echoing the "Capsule-Protocol: ?1" header in their response.
Clients of this specification MAY implement "connect-tcp", "connect-tcp-capsule", or both. Accordingly, templated TCP proxy servers for arbitrary clients MUST implement both Upgrade Tokens.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see why servers MUST implement both. One solution could be to use SHOULD instead (see below). Another option would be to add a sentence saying that servers that only expect one kind of client MAY only implement one of these Upgrade Tokens.

Suggested change
Clients of this specification MAY implement "connect-tcp", "connect-tcp-capsule", or both. Accordingly, templated TCP proxy servers for arbitrary clients MUST implement both Upgrade Tokens.
Clients of this specification MAY implement "connect-tcp", "connect-tcp-capsule", or both. Accordingly, templated TCP proxy servers for arbitrary clients SHOULD implement both Upgrade Tokens to improve compatibility.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I've rephrased this to highlight an exemption for restricted deployments.


When using the Capsule Protocol, TCP payload data is sent in the payload of a new Capsule Type named DATA ({{data-capsule}}). The ordered concatenation of DATA capsule payloads has the same semantics as what would have been sent on the data stream if the Capsule Protocol were not in use. It is applicable whenever use of the Capsule Protocol is optional.
When using "connect-tcp-capsule", TCP payload data is sent in the payload of a new Capsule Type named DATA ({{data-capsule}}). The ordered concatenation of DATA capsule payloads represents the main payload data stream in any protocol where this is well-defined. Intermediaries MAY split or merge DATA capsules. Endpoints MAY indicate a TCP connection error by sending an incomplete DATA capsule, as an alternative to using TCP, TLS, or HTTP stream errors.

# Additional Connection Setup Behaviors

Expand Down