We received feedback on our new X-Trace-Id response header support for Spring Boot 3.5 (see #40857). Instead of using an X- header we could be considering one of the currently developed drafts.
It seems both traceresponse and Server-Timing are being considered at the moment, with no clear guidance from the observability community. As far as I understand, Server-Timing has the following priorities:
This specification enables a server to communicate performance metrics about the request-response cycle to the user agent. It also standardizes a JavaScript interface to enable applications to collect, process, and act on these metrics to optimize application delivery.
Browsers can use this header to include its information in their "Developer tools" tabs to give the full picture of the web page performance: from backend activity to resource loading and HTML rendering. The traceId information would only be useful if this UI is also capable of retrieving and rendering the full trace information in the same context.
I think we'll go with the traceresponse header and the related format, as its main goal is to identify a completed request in a tracing system, which better aligns with our intent here.
Comment From: kzander91
@bclozel Wouldn't it make sense make the header name configurable? Additionally, is there a reason for not supporting this for WebFlux?
Comment From: bclozel
Wouldn't it make sense make the header name configurable?
I'm not sure I understand; how would that work?
Additionally, is there a reason for not supporting this for WebFlux?
No, I'm working on it. We were just waiting for community feedback before expanding support.
Comment From: kzander91
I'm not sure I understand; how would that work?
Instead of using this constant here:
https://github.com/spring-projects/spring-boot/blob/4c372679218cf3db1510a337f284e140101074c5/spring-boot-project/spring-boot-actuator-autoconfigure/src/main/java/org/springframework/boot/actuate/autoconfigure/observation/web/servlet/TraceHeaderObservationFilter.java#L38-L40
The filter gets a bean property traceIdHeaderName that is being populated by ObservationFilterConfigurations from a new property, something like management.observations.http.server.requests.trace-header-name=x-my-custom-trace-id-header-name.
We were just waiting for community feedback before expanding support.
I see, thank you.
Comment From: bclozel
@kzander91 but what would be the purpose of changing the header name? X-Trace-Id, traceresponse and Server-Timing all have different formats for the header value. What would be the goal?
Comment From: kzander91
Sorry, I missed that we're not just discussing header names, but also different header values (i.e. formats). I guess if we're using established header names, it would not make sense to make them customizable, you're right.
In my app, I have built a filter myself that exposes the trace id as a response header (under a name I have chosen myself). If this topic was just about exposing the trace id, and the header name was configurable, I could have replaced my own filter with Boot's new filter.
Comment From: bclozel
No worries @kzander91 I was just making sure I didn't miss anything.
As for the custom header that was our original intent but we got feedback and apparently that's not what people expect. Hopefully the "traceresponse" will be more adopted in the future.
Comment From: bclozel
Changes are now ready but on hold, as we are discussing with the Micrometer team whether this feature belongs in Micrometer directly.