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

[Walt Karas <wk...@yahooinc.com.INVALID>]

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 <ro...@apache.org> wrote:

> +1
>
> IMO we should have APIs for all SSL/SNI data.
>
> On Tue, Oct 5, 2021 at 11:25 AM Leif Hedstrom <zw...@apache.org> 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 <randallmeyer@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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_trafficserver_pull_8313&d=DwIFaQ&c=sWW_bEwW_mLyN3Kx2v57Q8e-CRbmiT9yOhqES_g_wVY&r=bRwMsdu0uyXK0N-ngQ91KF2IzpTwU-AXjOlCZnyKc_4&m=Tw5Nx95QZ9igI8Hl65kqtpzUO_yfLgq3zxd0vZPNIdw&s=wRrrS5YvSxROfyJVZrMRdrD_iC_dcAqotGW6eTvh5eM&e=
> > >
> > > -Randall
> >
> >
>