Repository navigation
[SR] Network Details - Rationalize regexp matching #5432
Description
Description
https://docs.sentry.io/platforms/javascript/session-replay/configuration/#network-details
UI screenshot (session replay -> "Network" -> select http request from list)
The SDK currently lets clients specify EITHER a regexp OR a regular url as a String - and the SDK doesn't know whether the client meant to provide a regexp or an absolute url - it just does String#matches
So for example // See docs.sentry.io
SentryAndroid.init(this) { options ->
options.sessionReplay.networkDetailAllowUrls = listOf("www.google.com")
}Can match unintended URLs like
"wwwXgoogleXcom".
This behaviour differs from
JS SDK - in JS RegExp is a first-class type and the SDK can do 'typeof' or similar
iOS SDK - has a swift protocol to enforce specifying whether the input is String or NSUrlExpression
Impact
For sentry-java It does not seem a huge deal, b/c most developers will test the urls they provide.
TODO: are there severe edge-cases that result in details being captured for unexpected urls?
For sentry-react-native, the SDK will passthrough SentryReplayOptions to the underlying native impls on sentry-java|cocoa - it may introduce more of an issue as the behaviour will fork.
Proposed Changes
Not 100% sure tbh. The concrete soln seems to follow the JS/iOS path of having a way to differentiate whether the String provided is a regexp or an actual url. But that seems like a big lift (API changes)
Activity
linear-code commentedon May 13, 2026
JAVA-513
adinauer commentedon May 15, 2026
This likely affects more options in the SDK like trace propagation targets, so when implementing, we should make sure to tackle all of them.
If we want to allow config from simple config files like Android Manifest, sentry.properties and Spring application.properties/application.yml we could add another config option to configure whether to strictly only use String matching on those URLs.
We could do this with one flag globally or one per other option it configures (probably globally is enough).
We could also make this opt-in for now and not have to wait for the next major version, then flip the option in the next major.
43jay commentedon May 19, 2026
I can't speak to the areas like trace propagation targets.
However
^For session replay, getsentry/sentry-react-native#4106 tracks this for sentry-react-native.
Assuming 2 things:
sentry-java/sentry-cocoaimpls under the hood. // specifically it will pass the specifiednetworkDetailAllow|DenyUrlsto the underlying native SDK.A global flag (something like
SentryReplayOptions.strictUrlMatching?) could cause headache whensentry-react-nativeis pushing config downwards.sentry-react-nativewill need to enforce the same strict matching config. This will be overly constrained b/c iOS does not, and lose some of the 'niceness' of how JS lets you deal withRegExps.Propose 1 : Per-entry typed matcher (iOS-style sealed type).
io.sentry.session-replay.network-detail-allow-urlsio.sentry.session-replay.network-detail-allow-urls-exact// absolute urlsio.sentry.session-replay.network-detail-allow-urls-regex// regexp urlsCHANGELOG was introduced in #4919 which was relatively recent Nov 2025. Curious whether we can look at data to see how many clients are using the current API (if any at all) to determine the scope of modifying the API.
runningcode commentedon May 26, 2026
Thanks for reporting and for the proposals. We will investigate this further and add this to our backlog.