> On Oct 7, 2021, at 1:54 AM, Masakazu Kitajo <mas...@apache.org> wrote:
>
> I'm +1 on adding it, but not sure about the name.
>
> There are a couple of similar APIs such as TSVConnSslCipherGet and
> TSVConnSslProtocolGet, and those start with "TSVConnSsl". TSVConnSslSNIGet
> may be more consistent with existing API names. It seems like TSSsl
> (without VConn) is used for APIs that purely interact with SSL stuff. Also
> only the first characters of acronyms are capital in many cases (not all).
> In that sense TSVConnSslSniGet, maybe.
Good point, and seeing that this acts on a TSVConn, we ought to stick to that
naming convention.
— Leif
>
> Masakazu
>
> On Wed, Oct 6, 2021 at 2:02 AM Randall Meyer <randallme...@yahoo.com.invalid>
> wrote:
>
>> Hello!
>> I'd like to propose adding a new API get grab the SNI from the client
>> connection.
>>
>> const char * TSSslSNIGet(TSVConn sslp, int *length)
>>
>> This would remove some of the redundant code in the rate_limit plugin but
>> also would allow for the rate_limit plugin to be used under BoringSSL. The
>> APIs between OpenSSL and BoringSSL here are pretty different here and don't
>> have access to the same underlying structs. We already save off the name in
>> the core (for both open and boring) and this API just exposes that value.
>>
>> Here is the PR showing the changes (both the API addition and code
>> cleanup). This would be split into 2 PRs if this API addition is accepted.
>>
>> https://github.com/apache/trafficserver/pull/8313
>>
>> -Randall
>>
