How can I query by an HTTP header that contains dashes in its name?

[elvis-segovia]

For example, I have the following header:

http.response.header.x-trace-id=77c575993913c7eace87a42574d5e3c6

Filtering by a header without dashes works correctly. For example:

server.address=my-server.jaeger.local

Is there a special syntax or escaping required for attribute names that contain dashes?

[dlanov]

Yes, there is a quoting syntax required — wrap the attribute key in double quotes when it contains dashes or other non-word characters:

"http.response.header.x-trace-id"=77c575993913c7eace87a42574d5e3c6

Why this happens

Jaeger's tag search parser treats unquoted attribute names as plain identifiers. Dots (.) are fine since the parser is aware of OTel-style dotted keys, but dashes (-) are ambiguous — they can be interpreted as a minus operator or a token boundary depending on the parser state. Quoting the entire key removes the ambiguity and forces it to be
treated as a literal string.

This applies to any attribute name that contains:

• Dashes: x-trace-id, content-type
• Special characters: @, #, brackets
• Keys that start with a number

Attribute value quoting

If the value also contains special characters, quote that too:

"http.response.header.x-trace-id"="77c575993913c7eace87a42574d5e3c6"

Why server.address works unquoted

server.address contains only alphanumeric characters and dots — all safe for the unquoted identifier parser. Keys like x-trace-id introduce a dash which the tokenizer doesn't handle the same way.

Backend note
This behavior is consistent across Jaeger's supported backends (Elasticsearch, OpenSearch, Badger, Cassandra) because the quoting is resolved at the query parsing layer before the backend-specific query is constructed — the backend never sees the raw dash.

[elvis-segovia]

Hi @dlanov, thanks for the reply! After doing some research, I found that the issue is with Elasticsearch. While there isn't much documentation on this, it appears to be related to the OpenTelemetry spec (https://opentelemetry.io/docs/specs/semconv/registry/attributes/http/). The root cause is that Elastic is saving the headers as an array.