You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current defaults for tracePropagationTargets (['localhost', /^\/(?!\/)/]) run into a few problems:
If you do a fetch request to the same origin domain without using a short version (i.e. fetch("https://mysameorigin.com/api/some-route") instead of fetch("/api/some-route")) we will currently not attach tracing headers by default.
If you use localhost with subdomains (e.g. http://cdn.localhost/resource) we will add tracing headers which may trigger CORS even for localhost.
Currently, we don't attach tracing headers to requests like fetch("//sameorigin.com/") while it would be valid to do so if sameorigin.com is actually the same origin.
Proposal
We need to be stricter on the localhost validation, e.g. /^(https?|ws):\/\/localhost//
We need to add a matcher for when the origin is provided and it is the same origin as the current page, e.g. new RegExp(`^${window.location.origin}\/`)
(Requirement: No longer support IE11) When a URL starts with a /, e.g. //external-origin.com/, we throw it into the URL constructor as follows and use the resulting origin as the base for matching against items in tracePropagationTargets: new URL(target, window.location.origin). That way, we are matching the actual resolved (including the protocol) against our defined tracePropagationTargets and it will work well with our predefined defaults. Maybe there is a case to be made to generally throw the target in the URL constructor before comparing against anything.
The text was updated successfully, but these errors were encountered:
@mydea There is definitely an argument to doing it already. I wasn't sure if it is technically breaking though 🤔 Touching tPT is kinda scary because the errors that could result from it are very hight impact.
@lforst amazing thanks for this! I was about to raise that last point as a bug/feature request, before I found this. Our code has been inconsistently using full URLs in some places, and just the path in others, and it took me a long time to realise this is why distributed tracing wasn't working consistently when tracePropagationTargets was defined
The current defaults for tracePropagationTargets (
['localhost', /^\/(?!\/)/]
) run into a few problems:fetch("https://mysameorigin.com/api/some-route")
instead offetch("/api/some-route")
) we will currently not attach tracing headers by default.http://cdn.localhost/resource
) we will add tracing headers which may trigger CORS even for localhost.fetch("//sameorigin.com/")
while it would be valid to do so ifsameorigin.com
is actually the same origin.Proposal
/^(https?|ws):\/\/localhost//
new RegExp(`^${window.location.origin}\/`)
/
, e.g.//external-origin.com/
, we throw it into the URL constructor as follows and use the resulting origin as the base for matching against items intracePropagationTargets
:new URL(target, window.location.origin)
. That way, we are matching the actual resolved (including the protocol) against our definedtracePropagationTargets
and it will work well with our predefined defaults. Maybe there is a case to be made to generally throw the target in the URL constructor before comparing against anything.The text was updated successfully, but these errors were encountered: