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
{{ message }}
Repository navigation
Tracing headers are attached to protocol-relative URLs by default, causing CORS errors #8099
custom headers added to requests and causes CORS error
Expected Result
Based on my understanding of the line const DEFAULT_TRACE_PROPAGATION_TARGETS = ['localhost', /^\//];Link, I would expect custom headers to only be added to non-cross-origin requests by default. This would be the case if the requests are targeting 'localhost' or if the request URL starts with a '/'.
However, I've noticed that this logic might not account for protocol-relative URLs (those starting with //, like //example.com). If my understanding is correct, this could potentially result in custom headers being added to these types of requests, which might not be the intended behavior
Actual Result
custom headers added to requests and cause CORS error.
If possible, I can submit a pull request to address this issue.
Based on my understanding of the line const DEFAULT_TRACE_PROPAGATION_TARGETS = ['localhost', /^//]; Link, I would expect custom headers to only be added to non-cross-origin requests by default
Yes, that's exactly how the default value should behave.
However, I've noticed that this logic might not account for protocol-relative URLs (those starting with //, like //example.com).
Hmm you're right, this would match with the /^\// default regex. But to be honest, I didn't know that this is a valid and usable URL. Can you show us a concrete reproduction? Would fetch('//example.com') be one of them?
Based on my understanding of the line const DEFAULT_TRACE_PROPAGATION_TARGETS = ['localhost', /^//]; Link, I would expect custom headers to only be added to non-cross-origin requests by default
Yes, that's exactly how the default value should behave.
However, I've noticed that this logic might not account for protocol-relative URLs (those starting with //, like //example.com).
Hmm you're right, this would match with the /^\// default regex. But to be honest, I didn't know that this is a valid and usable URL. Can you show us a concrete reproduction? Would fetch('//example.com') be one of them?
Yes, fetch('//example.com') could reproduce this situation.
changed the title [-]`sentry-trance` and `baggage` header for request url like `//xxx.com` causes cors error[/-][+]`sentry-trace` and `baggage` header for request url like `//xxx.com` causes cors error[/+]on May 15, 2023
changed the title [-]`sentry-trace` and `baggage` header for request url like `//xxx.com` causes cors error[/-][+]Tracing headers are attached to protocol-relative URLs by default, causing CORS errors[/+]on May 15, 2023
Activity
Lms24 commentedon May 11, 2023
Hi @gongpeione thanks for writing in!
Yes, that's exactly how the default value should behave.
Hmm you're right, this would match with the
/^\//default regex. But to be honest, I didn't know that this is a valid and usable URL. Can you show us a concrete reproduction? Wouldfetch('//example.com')be one of them?gongpeione commentedon May 12, 2023
Yes,
fetch('//example.com')could reproduce this situation.[-]`sentry-trance` and `baggage` header for request url like `//xxx.com` causes cors error[/-][+]`sentry-trace` and `baggage` header for request url like `//xxx.com` causes cors error[/+][-]`sentry-trace` and `baggage` header for request url like `//xxx.com` causes cors error[/-][+]Tracing headers are attached to protocol-relative URLs by default, causing CORS errors[/+]