Add accessor for logPrefix in ClientResponse to allow tying a ClientRequest to a ClientResponse

[epiwd]

Affects: spring-framework:spring-webflux:5.1.9.RELEASE

---

Hello,

I have a use case while making webclient requests where we use parts of the clientrequest and clientresponse together to form a log. In the clientRequest, logPrefix is an accessible unique identifier that is passed from the request to the response, yet when we try to do the same for the clientResponse, the field is present but not accessible.

We've considered a workaround where we create a custom ExchangeFunction that forces the logPrefix id into the headers of the clientRequest so that it can be read in the response, but even then, DefaultClientResponse is package-protected, which makes creating the ExchangeFunction difficult.

There is also a possibility we've overlooked a solution for this, so if there's a way to easily tie together a webclient request and response, please let me know.

If not, our proposed fix is simply to expose the logPrefix like all the other clientResponse fields.

Thank you!

[poutsma]

I don't it's a good idea to expose the logPrefix field in the ClientResponse interface, as it's an implementation detail of DefaultClientResponse that has does not deserve an accessor.

We could, however, expose the HttpRequest that is available in DefaultClientResponse as well. Would that help?

[rstoyanchev]

The logPrefix() in ClientRequest, as well as in ServerWebExchange on the server side, is meant to provide applications and the framework with a common handle for logging, that applications can also control via a well-known request attribute. As such it is part of the public API. From that perspective perhaps it does make sense to expose via ClientResponse. It could be documented as the logPrefix used for the request, if any.

[epiwd]

If the HttpRequest were available in the ClientResponse, that would work as well.

(To be even more explicit, we're trying to use ExchangeFilterFunctions to create a log line using both the request and response, but there's seemingly nothing built-in that can tie a request to a response.)

[rstoyanchev]

but there's seemingly nothing built-in that can tie a request to a response

In the public API you mean. Indeed it does seem like a missing link there for further logging downstream, e.g. in an onStatus handler or when handling a ClientResponseStatusException.

[poutsma]

I did not know that ClientResponse already exposed the logPrefix, so for consistency's sake I added it to ClientResponse as well.

If you (or anyone else) would like to see ClientResponse expose the HttpRequest as well, then please file a separate issue for that.

[epiwd]

Thanks for the fast turnaround!