I like the idea. I think this adds a lot of flexibility that can be useful
for logging.
I agree that "?:" looks like a ternary operator. It also makes it seem like
there is only one fallback but the code allows multiple. +1 on "??"
And +1 on allowing hard coded fallbacks. Since this feature introduces
fallbacks, I think it is a good opportunity to also allow users to
customize our default fallback ("-")
Best,
Serris Santos
On Mon, Mar 30, 2026 at 7:52 AM Chris McFarlen <[email protected]> wrote:
> This seems good. I think `?:` looks too much like a ternary operator. I
> recommend `??` as there is some precedence for that to mean "or this".
>
> Chris
>
>
> Sent with Proton Mail secure email.
>
> On Tuesday, March 24th, 2026 at 9: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
> >
>
