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:38 AM PDT, Leif Hedstrom <zw...@apache.org> wrote: > 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 >>
