[
https://issues.apache.org/jira/browse/TS-5030?focusedWorklogId=31572&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31572
]
ASF GitHub Bot logged work on TS-5030:
--------------------------------------
Author: ASF GitHub Bot
Created on: 03/Nov/16 23:05
Start Date: 03/Nov/16 23:05
Worklog Time Spent: 10m
Work Description: Github user calavera commented on the issue:
https://github.com/apache/trafficserver/pull/1184
1) > There are APIs to get the two components that you are asking for, all
you are doing is doing the string concatenation? That doesn't seem worth an
entirely new API to me.
The problem is that ATS defines how to concatenate those values inside the
log format. If you want to keep logs and plugins consistent, you need to look
at the code to see how the log generates the client request id.
From an administrator point of view, I don't care how that value in my log
is generated, I do care about having the same consistent value across logs,
server and plugins.
From a developer point of view, the only way to keep that consistency is to
replicate what ATS' log is doing. The only way to do that is by looking at the
code. This breaks the purpose of having a well defined api.
2) Assuming we want this, you definitely should not use the TS APIs in the
InkAPI.cc implementation of the new API. You should use the same underlying
APIs that are provided by the core implementation of the UUID and HttpSM
respectively.
I can make the changes accordingly.
Issue Time Tracking
-------------------
Worklog Id: (was: 31572)
Time Spent: 40m (was: 0.5h)
> Proposal: Add API to get the client request UUID directly from a TSHttpTx
> -------------------------------------------------------------------------
>
> Key: TS-5030
> URL: https://issues.apache.org/jira/browse/TS-5030
> Project: Traffic Server
> Issue Type: Improvement
> Components: TS API
> Reporter: David Calavera
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The new UUID api introduced in
> https://github.com/apache/trafficserver/pull/736 is great for tracing
> operations and requests. However, the most useful information for plugin
> developers, the unique client request id, is not exposed as an api endpoint.
> People need to understand very well how TrafficServer works internally to
> generate this value. By not having the API directly exposed, people need to
> repeat the same code every time they want to generate this unique identifier.
> I'd like to add an API enpoint to generate this identifier based in a given
> http transaction for plugins to use.
> This would be the signature:
> tsapi const char * TSClientRequestUuidGet(TSHttpTxn txnp);
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
