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 <r...@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 <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://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 > > > > >
