I wonder if this should be something ATS core provides.
It would be handy if ATS core supports this, but technically a
similar thing could be done with the new plugin API that I recently added,
and I'm afraid of making the logging syntax too complicated. Elvis operator
(:?) would make me want to use the ternary operator,
%<{@foo}cqh>?%<abc>:unavailable>.
It would be more flexible and powerful, if header_rewrite or something got
a feature to register a new log field. With Cripts, I guess we could even
do masking on plugins.
So I'm not throwing -1 at this point, but I'd like to see a border line.
What should be done by ATS core?
-- Masakazu
On Tue, Mar 24, 2026 at 8:48 AM Brian Neradt <[email protected]> wrote:
> Hi [email protected],
>
> I wanted to invite feedback on a small logging feature I’m working on for
> ATS by request from our ops team. ATS currently supports transactional
> logging of specific header field values with expressions such as:
>
> %<{x-primary-id}cqh>
>
> `cqh` is the ATS log formatting field that prints the value of a particular
> client request header field, in this case x-primary-id. Today, if that
> header is not present, ATS logs the normal missing value, `-`. The proposed
> feature allows a fallback chain so users can log an alternate header when
> the primary one is absent.
>
> Example:
>
> %<{x-primary-id}cqh?:{x-secondary-id}cqh>
>
> Note the `?:`, the proposed operator which signals the chain. This is
> evaluated left to right:
>
>
> - If x-primary-id exists, log that
> - Otherwise if x-secondary-id exists, log that
> - Otherwise log -
>
>
> A few notes about the current behavior:
>
> - This alternate chain feature is limited to header field log formats
> for now (cqh, pqh, ssh, etc.).
> - The chain can contain an arbitrary set of alternate field names (i.e.,
> not just one alternate, but two, three, etc.).
> - An existing header field with an empty value is treated as present.
>
>
> Slices remain per-candidate, so this is valid:
>
> %<{x-primary-id}cqh[0:8]?:{x-secondary-id}cqh[0:16]>
>
> The goal is to make log configuration more flexible for deployments that
> need to accommodate multiple header conventions for the same type of data
> without duplicating formatting fields and requiring post-processing of
> transaction logs.
>
> For reference, here is a PR that implements this feature:
>
> https://github.com/apache/trafficserver/pull/13018
>
> Please let me know if you have feedback or concerns. If you have ideas
> other than the `?:` operator, for instance, I'm definitely open to trying
> something else.
>
> Thanks!
> Brian Neradt
>
> --
> "Come to Me, all who are weary and heavy-laden, and I will
> give you rest. Take My yoke upon you and learn from Me, for
> I am gentle and humble in heart, and you will find rest for
> your souls. For My yoke is easy and My burden is light."
>
> ~ Matthew 11:28-30
>
