This PR addresses issue #36168

Summary

• Added an opt-in mechanism to selectively propagate headers from an input Message to the outbound Message created by:

  • SendToMethodReturnValueHandler
  • SubscriptionMethodReturnValueHandler

• Header propagation is controlled via a configurable Predicate<String>.

• Default behavior remains unchanged: no headers are propagated unless explicitly configured.

Resolved Issue

• Allows applications to forward selected headers (e.g. correlation or receipt-related headers) while avoiding accidental propagation of internal or protocol-specific headers.
• Provides a simple and explicit customization point instead of always copying or discarding headers.

Scope

• This change applies only at the Spring Messaging layer.
• It affects how outbound MessageHeaders are populated by handler return value processing.
• It does not change STOMP native header serialization or WebSocket frame encoding.

Discussion Points

• Whether the public getter (getHeaderPropagationPredicate) should be retained, or removed to keep the API strictly write-only.
• The current scope of this PR is limited to propagating headers at the Spring Messaging level.
  A discussion point is whether this is sufficient for the intended use cases, or if extending the mechanism to STOMP native headers should be considered separately rather than as part of this change.

I've applied the requested changes (renaming to headerFilter, switching to add~ method with Predicate#or logic, and adjusting the execution order). I've squashed the changes into the main commit to keep the history clean as per the contribution guide. Sorry for making the delta review slightly harder.

No problem, I added an additional property on SimpAnnotationMethodMessageHandler to make it a little easier to configure.

Hi @rstoyanchev,

When I was working on this PR, I found that the propagated headers didn't actually reach the STOMP client. There are two issues:

Input side: STOMP custom headers (e.g. x-correlation-id) are stored inside the nativeHeaders sub-map, not as top-level MessageHeaders entries. So when headerFilter iterates over top-level keys, it never matches them.

Output side: Even if headers were copied to the top-level MessageHeaders, StompEncoder.writeHeaders() only serializes entries from the nativeHeaders sub-map, so they would never be written to the outbound STOMP frame.

That's why I had left it as a discussion point in the PR. Is the current scope what you intended, or should we extend propagation to STOMP native headers as well? If it makes sense to extend, I'd be happy to follow up with a PR.

@catturtle123 thanks for the reminder on that, I did miss the note on native headers. One option is to apply the predicate at both levels, but ultimately the original request is about propagating native headers to the broker, so we should amend the the solution to apply the predicate on native headers.

I am re-opening in order to append the extra commits here and keep this as the main issue, but if you would like to submit the changes, you can send a new PR, and I will just pick the commits from there. Please, keep in mind 7.0.4 is due this week so do let me know if you're able to submit the changes before then.

@rstoyanchev

I've updated the implementation to apply the predicate on native headers instead of Spring Messaging-level headers. The createHeaders() method now uses SimpMessageHeaderAccessor.wrap() to extract native headers from the input message and propagates matching ones via setNativeHeaderValues().

The changes have been pushed. Let me know if anything else needs to be adjusted.

PR address: #36282

(I accidentally closed this PR while updating the branch.....)

This is in now. I simplified the access to the native headers map to avoid creating copies of the map.

Thanks for the review and polishing!