extensions-negotiation definition
#112
Conversation
|
concept ack |
|
@Fi3 @TheBlueMatt @jakubtrnka this PR is ready for review |
|
@Fi3 just a reminder to approve this, as we agreed during yesterday's call |
| | Field Name | Data Type | Description | | ||
| |------------------------|--------------|-----------------------------------------------| | ||
| | request_id | U16 | Unique identifier for pairing the response. | | ||
| | unsupported_extensions | SEQ0_64K[U16]| List of unsupported extension identifiers. | |
There was a problem hiding this comment.
I would add a field called requested_extension with extension that server require but are not in RequestExtensions from client.
There was a problem hiding this comment.
Don't you think extensions should be requested only by the client? Do you some tangible examples for the opposite case?
There was a problem hiding this comment.
a pool accept only client that have an extension for example I want the client to use a specific accounting or auditing system
| | request_id | U16 | Unique identifier for pairing the response. | | ||
| | supported_extensions | SEQ0_64K[U16]| List of supported extension identifiers. | | ||
|
|
||
| ### `RequestExtensions.Error` (Server -> Client) |
There was a problem hiding this comment.
What happens if upstream returns RequestExtensionsError? are they expected to drop the connection?
There was a problem hiding this comment.
we don't need to drop the connection here. Client based on the server response can decide if:
- continue with extension requested by up and/or continue without ext not supported by up
- drop connection (if for example up do not support an ext that is mandatory for cli)
This PR defines extension n.1 which allows for any implementation to support future extensions in a clean and scalable way.
Close #111