Repository navigation
Make tracePropagationTargets matching case-insensitive #16018
Description
Problem Statement
Currently, we have a bit of an obscure problem with tracePropagationTargets:
If users make a fetch request to a URL with casing (for whatever reason), they likely apply the same casing when defining tracePropagationTargets:
Sentry.init({
tracePropagationTargets: ['myApi.com', /^myApi.com\/.*/]
})
fetch('https://myApi.com');Unfortunately, the values in tracePropagationTargets counter-intuitively don't match because we create a new URL() from the URL passed to fetch when determining if our tracing headers should be attached.
The constructed URL object converts the entered url though to all-lower-case, meaning that when matching myapi.com against both, the string or the regex, we wouldn't get a positive match. Therefore, the currently correct way of specifying TPT for this URL would any one of :
Sentry.init({
tracePropagationTargets: [
'myapi.com',
/^myapi.com/,
/^myApi.com/i,
]
})Solution Brainstorm
For simplicity, we propose to convert all entries in tracePropagationTargets .toLower() and add a case insensitivity /i flag to RegExp values.
We're a bit worried though about subtly breaking existing setups that perhaps rely on case sensitivity. Therefore we consider this behaviour-breaking and opt to make the change in the next major.
(Also, intuitively, this sounds like a niche/edge case as it's rather uncommon to capitalize URLs)
Activity
[-]Make `tracePropagationTargets` case-insensitive[/-][+]Make `tracePropagationTargets` matching case-insensitive[/+]mydea commentedon Apr 9, 2025
How would you depend on this behavior today? I just wonder if there is really a case where we would unintentionally break something vs. it suddenly starting to behave as I want? If a user has configured a trace propagation target
myapi.comI find it extremely unlikely that they would expect/depend on requests tomyApi.comnot being propagated? And on the other hand, if they specifiymyApi.comit is obviously a bug that this will not match anything, basically.So my POV is: this is a bug and was never supposed to be case insensitive, so I would just fix it 😅
Lms24 commentedon Apr 9, 2025
I think the concrete concern was places where it's more likely to actually encounter capitalized letters, like query params.
So maybe something like
'myApi/users?traceRequest=1'though now that I think about it, this would only be a problem if we there was a specific all lower case param and a camel-cased version of the same parameter, so rather unlikely?
The overall concern: Right now, we (unexpectedly) would not attach headers to a variety of requests. Maybe users depend on this inderectly, in the sense that if we changed it, they'd get CORS errors because they didn't realize it was a problem before. So it's kinda a spacebar heating situation xD
mydea commentedon Apr 11, 2025
no strong feelings, we can also leave it for v10! I'll leave the decision to you ;)
AbhiPrasad commentedon Apr 14, 2025
huh I didn't do this 😅
Linear weirdness?
feat(core)!: Make `tracePropagationTargets` matching case-insensitive (…
github-actions commentedon Sep 23, 2026
A PR closing this issue has just been released 🚀
This issue was referenced by PR #23534, which was included in the 11.0.0 release.