Change X-Trace-Id response header in favour of "traceresponse"

[bclozel]

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.

[kzander91]

@bclozel Wouldn't it make sense make the header name configurable? Additionally, is there a reason for not supporting this for WebFlux?

[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.

[kzander91]

I'm not sure I understand; how would that work?

Instead of using this constant here:

spring-boot/spring-boot-project/spring-boot-actuator-autoconfigure/src/main/java/org/springframework/boot/actuate/autoconfigure/observation/web/servlet/TraceHeaderObservationFilter.java

Lines 38 to 40 in 4c37267

	private static final String TRACE_ID_HEADER_NAME = "X-Trace-Id";

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.

[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?

[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.

[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.

[bclozel]

Changes are now ready but on hold, as we are discussing with the Micrometer team whether this feature belongs in Micrometer directly.

[bclozel]

The original attempt has been reverted in #44752. The "traceresponse" implementation is quite straightforward.

But it sounds like there is no strong consensus in the community nor in the industry about which header and format should be adopted for this. In the meantime, developers can override a protected method in the filter and contribute this as a bean, as seen in spring-projects/spring-framework#30632 (comment).

Depending on how things evolve, we might consider this as a Spring Boot feature or Micrometer feature in the future.

[shakuzen]

Would users that are asking for this feature share some details about their use case? That may help us understand how to best deliver this feature and how generally applicable the need may be. I haven't seen much shared about the underlying need that's motivated this request.

[glyiu98]

I also have the same use case as @kzander91.
On my projects I am returning the traceId in the response headers for easier tracking.

I was also interested on having the choice of choosing a custom header name because I am using a service which expects a specific header name (different from the default you are proposing).

[bclozel]

Thanks for your feedback @glyiu98 !

If you need a custom header format then you can achieve that already with #44431 (comment)
This issue wouldn't help at all in your case then.

I would be interested to learn more. Can you name the service that is using this header and which format it is expecting?

[glyiu98]

Yes indeed, that’s what we currently have in place.

We have that constraint because our infra team have setup some analytics events for the API calls which would look for the specific response header “Correlation-Id”, so it was more because of a custom configuration :D

[shakuzen]

On my projects I am returning the traceId in the response headers for easier tracking.

I'm hoping to get more details about what that means. Presumably you're using a distributed tracing system, which doesn't use the trace ID in the response headers, so I'm wondering how it is being used. I presume it is some other system for some other purpose.