-
Notifications
You must be signed in to change notification settings - Fork 811
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CORS Preflight Requests not accounted for #5122
Comments
It's not really clear what you mean here. In the issue you say "CORS preflight requests are created as child spans of the main request" but in the PR you introduced it looks like you're actually removing this behavior? Are you saying the behavior doesn't work and should be removed for that reason? Or are you saying we shouldn't be creating these spans at all? |
Thank you for the reply. Exactly. The current code was built upon what seems a false assumption: that there's two Performance entries per each cross-origin request (one for the preflight/OPTIONS/CORS, another for the actual request). At least as per Resource Timing level 2, request preconditions (authentication, redirects, CORS) are accounted for as a part of the entry of the originator request. |
I'm re-labelling this as an enhancement since there's nothing wrong with the existing telemetry but we just have extra code that needs to be removed IIUC 🙂 |
What happened?
Currently XHR and Fetch instrumentation are treating CORS with the assumption that there's 2 entries (one for the actual request, another for the preflight) on the performance entry.
This is not the case.
Steps to Reproduce
web-opentelemetry-example
Expected Result
Actual Result
Additional Details
I believe this behaviour happens because according to Resource Timing Level 2:
Which means there's no duplicate entry performance entry in case of preflights.
OpenTelemetry Setup Code
package.json
Relevant log output
No response
The text was updated successfully, but these errors were encountered: