[
https://issues.apache.org/jira/browse/TS-2610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13919139#comment-13919139
]
Leif Hedstrom commented on TS-2610:
-----------------------------------
This feels a little weird, is this tied to some (yet to be committed) SPDY
features of the core? What I'm saying is, it feels the log tag values should
not be hardcoded like this, but should come from the ALPN / NPN negotiation.
Otherwise, how do we intend for this to work generically, and particularly, for
HTTP/2 once we support that ?
> Add "client_req_proto_type", %<cqpt> field into LogFormat
> ---------------------------------------------------------
>
> Key: TS-2610
> URL: https://issues.apache.org/jira/browse/TS-2610
> Project: Traffic Server
> Issue Type: New Feature
> Components: Logging
> Reporter: Yunkai Zhang
> Assignee: Yunkai Zhang
> Attachments:
> 0001-TS-2610-Indroduce-TSHttpConnectWithProtoType-API.patch,
> 0002-TS-2610-Add-client_req_proto_type-cqpt-field-into-Lo.patch
>
>
> This ticket was split from SPDY ticket(TS-2431).
> Add %<cqpt> field into LogFormat, so that we can distinguish the protocol
> type of each log record, it can help us to to do some analysis and statistic.
> Here are the available values of %<cqpt>:
> {code}
> "HTTP" -- HTTP protocol
> "HTTP_SSL" -- HTTP with SSL protocol
> "HTTP_SPDY" -- HTTP with SPDY protocol
> "HTTP_SPDY_SSL" -- HTTP with SPDY with SSL protocol
> {code}
> For some 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:
> {code}
> tsapi TSVConn TSHttpConnectWithProtoType(struct sockaddr const* addr,
> TSNetProtoType proto_type);
> {code}
> After introducing TSHttpConnectWithProtoType() API, TSHttpConnect() API would
> be a special case of it:
> {code}
> TSVConn
> TSHttpConnect(sockaddr const* addr)
> {
> return TSHttpConnectWithProtoType(addr, TS_NET_PROTO_HTTP);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
