Skip to content
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.

Sign up for GitHub

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

fix: multiple server-tracing headers aren't handled #1077

Merged
merged 2 commits into from
Nov 21, 2024
Merged

fix: multiple server-tracing headers aren't handled #1077

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
d572adc
fix: multiple server-tracing headers aren't handled
jtmalinowski Nov 20, 2024
1c3db17
PR feedback
jtmalinowski Nov 21, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 12 additions & 6 deletions splunk-otel-android/src/main/java/com/splunk/rum/RumResponseAttributesExtractor.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -28,6 +28,7 @@

class RumResponseAttributesExtractor implements AttributesExtractor<Request, Response> {

public static final String SERVER_TIMING_HEADER = "server-timing";
private final ServerTimingHeaderParser serverTimingHeaderParser;

public RumResponseAttributesExtractor(ServerTimingHeaderParser serverTimingHeaderParser) {
Expand All @@ -52,11 +53,16 @@ public void onEnd(
}

private void onResponse(AttributesBuilder attributes, Response response) {
String serverTimingHeader = response.header("Server-Timing");
String[] ids = serverTimingHeaderParser.parse(serverTimingHeader);
if (ids.length == 2) {
attributes.put(LINK_TRACE_ID_KEY, ids[0]);
attributes.put(LINK_SPAN_ID_KEY, ids[1]);
}
response.headers().forEach(header -> {
if (!header.getFirst().equalsIgnoreCase(SERVER_TIMING_HEADER)) {
return;
}

String[] ids = serverTimingHeaderParser.parse(header.getSecond());
if (ids.length == 2) {
attributes.put(LINK_TRACE_ID_KEY, ids[0]);
attributes.put(LINK_SPAN_ID_KEY, ids[1]);
}
});
}
}
10 changes: 4 additions & 6 deletions splunk-otel-android/src/test/java/com/splunk/rum/RumResponseAttributesExtractorTest.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -36,22 +36,20 @@ class RumResponseAttributesExtractorTest {

@Test
void spanDecoration() {
ServerTimingHeaderParser headerParser = mock(ServerTimingHeaderParser.class);
when(headerParser.parse("headerValue"))
.thenReturn(new String[] {"9499195c502eb217c448a68bfe0f967c", "fe16eca542cd5d86"});

Request fakeRequest = mock(Request.class);
Response response =
new Response.Builder()
.request(fakeRequest)
.protocol(Protocol.HTTP_1_1)
.message("hello")
.code(200)
.addHeader("Server-Timing", "headerValue")
.addHeader("Server-Timing", "othervalue 1")
.addHeader("Server-Timing", "traceparent;desc=\"00-9499195c502eb217c448a68bfe0f967c-fe16eca542cd5d86-01\"")
.addHeader("Server-Timing", "othervalue 2")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we know the circumstances that would cause this to happen? Seems a little strange, but doesn't violate the http spec, so I suppose the server side can do all kinds of odd things.

I think the test should should be enhanced to cover the case were there are 2+ Server-Timing headers, both of which are parseable but with different values. The logic currently reads like the last one "wins" .... is this intentional? If so, let's assert that intention with test coverage. 👍🏻 Thanks!

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @breedx-splk for your help.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CDN in the customer's account is adding its own Server-Timing. They have their own prefix instead of traceparent, so we can distinguish them.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In most header-emission apis, it is much easier to simply add a single header line than to find an existing one with the same key and then modify or upsert it. So, yes, this is probably going to happen. Likewise, header receipt apis differ in the guarantees they make in terms of how they present this situation (as a unified comma-separated list, as an array of values from a key, etc.). So, I think the client side of this should

  • search exhaustively for a Server-Timing metric named traceparent (across comma-separate values, across multiple header lines), but
  • make no guarantees about which one will be used if multiple (validly formed) traceparents are present (just do whatever is easier given the api surface we have at hand).

An alternative would be to add all found valid values as links, but that would require using actual otel span links (which do not require unique names and can have identical attribute keys/values) instead of our current link.* attribute pair. I'd consider that a future goal.

.build();

RumResponseAttributesExtractor attributesExtractor =
new RumResponseAttributesExtractor(headerParser);
new RumResponseAttributesExtractor(new ServerTimingHeaderParser());
AttributesBuilder attributesBuilder = Attributes.builder();
attributesExtractor.onStart(attributesBuilder, Context.root(), fakeRequest);
attributesExtractor.onEnd(attributesBuilder, Context.root(), fakeRequest, response, null);
Expand Down
Loading