On Mar 4, 2014, at 12:15 AM, Yunkai Zhang <yunkai...@gmail.com> wrote:
> I have opened a ticket(TS-2610<https://issues.apache.org/jira/browse/TS-2610>) > that add %<cqpt>(client_req_proto_type) field into LogFormat, so that we > can distinguish the protocol type of each log records. > > But for plugins that using TSHttpConnect() API to do request, the Logging > module can't know which protocol type is used, so I add a new API: > TSHttpConnectWithProtoType(struct sockaddr const* addr, > TSNetProtoType proto_type); > > After introducing TSHttpConnectWithProtoType() API, TSHttpConnect() API > would be a special case of it: > TSVConn > TSHttpConnect(sockaddr const* addr) > { > return TSHttpConnectWithProtoType(addr, TS_NET_PROTO_HTTP); > } > > The old plugins needn't to change anything if they do not care %<cqpt> > field, so the new API wouldn't cause compatibility issue. I think the TSNetProtoType name is confusing, it definitely confused me for a long time :) The purpose of this is to track the original protocol stack that we are doing work on behalf of, so I think that a name similar to TSClientProtoType would be clearer. This way of tracking the client protocol stack has the risk of combinatorial explosion. I think that we should separate out the transport and application protocols to make it easier to express TCP+HTTP, TLS+HTTP, TCP+WEBSOCKET, TLS+WEBSOCKET, TCP+SPDY, TLS+SPDY, etc. Finally, it seems that this is a property of the virtual circuit, so perhaps a better approach would be an API that can get and set the bitmask on a TSVConn? J
