-
Notifications
You must be signed in to change notification settings - Fork 10.2k
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
Set the baggage even when the trace id is not successfully extracted #55341
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some basic questions.
@cijothomas, could you please take a moment to share your thoughts on this PR? Thank you. |
open-telemetry/opentelemetry-dotnet#5667 Linking to couple of related issues. @joegoldman2 thanks for adding me! Agree with the statement that baggage should be extracted irrespective of tracecontext. I'll let owners of this repo review/share feedback. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The best I can say is that I'm not aware of a problem this could cause.
@@ -430,28 +430,33 @@ private void RecordRequestStartMetrics(HttpContext httpContext) | |||
} | |||
} | |||
|
|||
// The trace id was successfully extracted, so we can set the trace state | |||
// https://www.w3.org/TR/trace-context/#tracestate-header | |||
if (!string.IsNullOrEmpty(requestId)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect that checking requestId
has probably become redundant, but I'm fine keeping it in the spirit of making a conservative change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed that it is probably redundant, and also agreed that keeping the check anyways is the more conservative change :)
src/Hosting/Hosting/src/Internal/HostingApplicationDiagnostics.cs
Outdated
Show resolved
Hide resolved
No issues were apparent to me at least. Using baggage from an untrusted source is a potential security threat similar to any other untrusted on-the-wire input, but nothing in this change appeared to make that attack meaningfully easier to execute. At worst previously the attacker would have needed to add a randomly generated request id to their malicious message and now they don't need to do that. |
Co-authored-by: Noah Falk <noahfalk@users.noreply.github.com>
Thanks, @noahfalk! And thanks for your patience, @joegoldman2! |
Agreed, but it's not one of the usual suspects. @captainsafia for |
I just merged a fix for this in 4c8b5fe. We may have to use |
/azp run |
Azure Pipelines successfully started running 3 pipeline(s). |
Those failures are the usual suspects. 😆 |
Can't say I've ever seen that signalr failure before. @BrennanConroy?
|
/azp run |
Azure Pipelines successfully started running 3 pipeline(s). |
Latest CI failure is #53294 |
/azp run |
Azure Pipelines successfully started running 3 pipeline(s). |
/azp run |
Azure Pipelines successfully started running 3 pipeline(s). |
Fixes #50158.
Better to review it without whitespace diff: https://github.com/dotnet/aspnetcore/pull/55341/files?diff=unified&w=1.