I'll check out TSClientProtoStack. I think that would be similar to the
third option.
In the interest of getting Lev going, I will file a new bug and attach a
diff to implement TSVConnIsBlind. Even if we ultimately implement one
of the more general solutions, this will likely be a handy short cut for
plugin writers. Once it is there, I'll pass it around for official API
review. But if you see problems with this approach now, I'd appreciate
knowing sooner than later.
Thanks,
Susan
On 1/15/2015 11:32 AM, James Peach wrote:
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.
