I'm calling this vote with 5 +1 votes, and no -1’s. I'm going to name the API
TSVConnSslSniGet like Masakazu suggested.
The PR with this change is here:
https://github.com/apache/trafficserver/pull/8313
Thank you for all the comments received!
-Randall
On Thursday, October 7, 2021, 07:53
> On Oct 7, 2021, at 1:54 AM, Masakazu Kitajo 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
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
If we really want to swing for the bleachers, we could move all config into
a plugin. In a way that would allow a proxy to be managed with SNMP, gRPC,
etc. by replacing the plugin.
On Tue, Oct 5, 2021 at 12:33 PM Robert O Butts wrote:
> +1
>
> IMO we should have APIs for all SSL/SNI data.
>
> O
+1
Sent from my iPhone
> On Oct 5, 2021, at 6:29 PM, Brian Neradt wrote:
>
> +1
>
> Thanks Randall.
>
>> On Tue, Oct 5, 2021 at 12:33 PM Robert O Butts wrote:
>>
>> +1
>>
>> IMO we should have APIs for all SSL/SNI data.
>>
>>> On Tue, Oct 5, 2021 at 11:25 AM Leif Hedstrom wrote:
>>>
>>
+1
Thanks Randall.
On Tue, Oct 5, 2021 at 12:33 PM Robert O Butts wrote:
> +1
>
> IMO we should have APIs for all SSL/SNI data.
>
> On Tue, Oct 5, 2021 at 11:25 AM Leif Hedstrom wrote:
>
> > +1.
> >
> > I think the same pattern is in a couple of other “example” plugins as
> > well, which could
+1
IMO we should have APIs for all SSL/SNI data.
On Tue, Oct 5, 2021 at 11:25 AM Leif Hedstrom wrote:
> +1.
>
> I think the same pattern is in a couple of other “example” plugins as
> well, which could be cleaned up the same way.
>
> — Leif
>
>
> > On Oct 5, 2021, at 11:02 AM, Randall Meyer
>
+1.
I think the same pattern is in a couple of other “example” plugins as well,
which could be cleaned up the same way.
— Leif
> On Oct 5, 2021, at 11:02 AM, Randall Meyer
> wrote:
>
> Hello!
> I'd like to propose adding a new API get grab the SNI from the client
> connection.
>
> const
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 API