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
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.
The text was updated successfully, but these errors were encountered:
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.
Lms24
changed the title
sentry-trance and baggage header for request url like //xxx.com causes cors errorsentry-trace and baggage header for request url like //xxx.com causes cors error
May 15, 2023
Lms24
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
May 15, 2023
Is there an existing issue for this?
How do you use Sentry?
Sentry Saas (sentry.io)
Which SDK are you using?
@sentry/browser
SDK Version
7.48.0
Framework Version
No response
Link to Sentry event
No response
SDK Setup
Steps to Reproduce
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.
The text was updated successfully, but these errors were encountered: