> On Jan 15, 2015, at 9:13 AM, Susan Hinrichs > <shinr...@network-geographics.com> wrote: > > Lev noted in his experiments with blind tunneling SSL and transaction start > hooks, that the plugin API has no way to test whether a VC is blind tunneled > or not. That seems like a useful tool to the API writer. > > There are several ways this could be added to the API. > > Most straightforward, we could have a call like > bool TSVConnIsBlind(TSVConn vc) > which would be analogous to the existing > bool TSVConnIsSSL(TSVConn vc). > > We could have a call that returns the enumerated type of the vc, e.g., > TSVConnType TSVConnTypeGet(TSVConn vc) > where the TSVConnType would be one of blind, ssl, or normal(?). > > We could be ambitious and try to address a problem that has been growing with > the advent of SPDY and HTTP2, and add a function that returns a bit vector of > the protocols used by the vc, e.g., > TSProtoVector TSVConnProtocolsGet(TSVConn vc)
We used to have API for this named TSClientProtoStack. Check the source history for what this looked like. > > This would return a bit vector of protocols involved in this vc. So in the > blind tunnel case, no bits would be set. If this was HTTP/1.1 over TCP only > the HTTP/1.1 bit would be set. If this was HTTP/1.1 over SSL, both the SSL > and HTTP/1.1 bits would be set. If this was SPDY over SSL, both the SPDY and > SSL bits would be set. > > Let me know your thoughts. > >
