Re: [VOTE] new API for getting the SNI for a client connection

2021-10-18 Thread Randall Meyer
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

Re: [VOTE] new API for getting the SNI for a client connection

2021-10-07 Thread Leif Hedstrom
> 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

Re: [VOTE] new API for getting the SNI for a client connection

2021-10-07 Thread Masakazu Kitajo
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

Re: [E] Re: [VOTE] new API for getting the SNI for a client connection

2021-10-06 Thread Walt Karas
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

Re: [VOTE] new API for getting the SNI for a client connection

2021-10-05 Thread Sudheer Vinukonda
+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: >>> >>

Re: [VOTE] new API for getting the SNI for a client connection

2021-10-05 Thread Brian Neradt
+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

Re: [VOTE] new API for getting the SNI for a client connection

2021-10-05 Thread Robert O Butts
+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 >

Re: [VOTE] new API for getting the SNI for a client connection

2021-10-05 Thread Leif Hedstrom
+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

[VOTE] new API for getting the SNI for a client connection

2021-10-05 Thread Randall Meyer
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