Client libraries should use SNI and should test for compliance

[QuintinWillison]

We've identified that our Ruby client isn't sending SNI and this can cause issues at the server endpoint in some circumstances.

We should be doing our best to use SNI whenever we can and perhaps should also have a way of testing compliance for any given client library. Compliance may vary according to the underlying TLS implementation/runtime which needs to be considered when approaching test strategy.

See this Slack message and surrounding thread context for further details.

┆Issue is synchronized with this Jira Task by Unito

[ably-sync-bot]

➤ Tony Bedford commented:

Having read the description and Slack messages this doesn’t look like a docs issue as such (at least as yet), but was meant to be the basis for ongoing discussion. Leaving on Backlog for now.

[QuintinWillison]

@tbedford I was wondering if this might be an addition to the client library features specification, which is hosted in this repository.

Also, related: ably/ably-java#666

[kavalerov]

This does sound like a spec question to me, yes, fig we expect library implementations to do this.

@tbedford this is related to a comment I made elsewhere - art the moment library spec (effectively a product feature and implementation document) is part of this repo => we have issues like this in this repo. We may find a better way of managing this in the future, but it is the current state of things.

[ably-sync-bot]

➤ Tony Bedford commented:

Ultimately, I would like to get all client library spec content out of the docs repo and into a separate repo managed by SDK developers, with suitable input from tech writers from time to time.

We also need to decide what we call our SDKs, are we sticking with the current name “Ably Client Library SDK“, or switching to something like “Ably Platform SDK“.

[sync-by-unito]

➤ Automation for Jira commented:

The link to the corresponding Jira issue is https://ably.atlassian.net/browse/SDK-2774