GeezerVison

The proposed changed would be breaking. The original ServerTransportSecurityValidator has been shipped in a previous major. If you'd to contribute this, we need a deprecation path.

Updated with a deprecation path as suggested. The changes:

• validateHeaders(Map) is now a deprecated default method that bridges to the new validateHeaders(Function) via case-insensitive lookup
• Transport providers continue calling validateHeaders(Map), so existing custom implementations that override it won't break
• Added tests for both the deprecated Map-based API and the interface bridge behavior

@Kehrlann I've updated the PR with the deprecation path as you suggested. Would you mind taking another look when you get a chance? Thanks!

Hey @neerajbhatt ! Thanks for the update. So this adds a deprecation path but the transport does not use the new API. But that's the whole point in introducing this new API.

Let's try introducing a HeaderAccessor interface, with:

1. List<String> getHeader(String)
2. List<String> getHeaderNames()

And then ServerTransportSecurityValidator becomes (more or less):

@FunctionalInterface
public interface ServerTransportSecurityValidator {

	@Deprecated
	void validateHeaders(Map<String, List<String>> headers) throws ServerTransportSecurityException;

	default void validateHeaders(HeaderAccessor accessor) throws ServerTransportSecurityException {
		var collectedHeaders = accessor.getHeaderNames()
			.stream()
			.collect(Collectors.<String, String, List<String>>toUnmodifiableMap(String::toLowerCase,
					accessor::getHeader, (l1, l2) -> {
						var merged = new ArrayList<>(l1);
						merged.addAll(l2);
						return Collections.unmodifiableList(merged);
					}));
		validateHeaders(collectedHeaders);
	}
}

@Kehrlann Updated with the HeaderAccessor interface as you suggested. Here's a summary of the changes:

New files:

• HeaderAccessor — public interface with getHeader(String) and getHeaderNames()
• HttpServletHeaderAccessor — internal implementation wrapping HttpServletRequest, leveraging its native case-insensitive header lookup

Modified files:

• ServerTransportSecurityValidator — new validateHeaders(HeaderAccessor) default method; deprecated validateHeaders(Map) bridges to it by wrapping the map as a HeaderAccessor; the new method's default collects headers into a Map and calls the deprecated one — so existing custom implementations that override either method continue to work
• DefaultServerTransportSecurityValidator — overrides validateHeaders(HeaderAccessor) directly, querying Origin and Host via accessor.getHeader()
• 3 servlet transports — now call validateHeaders(new HttpServletHeaderAccessor(request)) instead of extractHeaders(request) + Map-based call

Removed:

• HttpServletRequestUtils — no longer needed

Tests:

• All 49 DefaultServerTransportSecurityValidatorTests pass
• Added accessorDefaultBridgesToMapOverride test verifying the reverse bridge (HeaderAccessor → Map) works for existing implementations

@Kehrlann Could you remove the "waiting for user" label? I believe all your feedback has been addressed in the latest iteration. Thanks!

By removing @FunctionalInterface, this becomes a breaking (binary-incompatible) change. Maybe we should use your original solution and target 3.0.

Please hold until we discuss this with the team.

@neerajbhatt are you still interested in this?

For context, 2026-07-28 is round the corner and this code will not evolve anymore.

Hi @Kehrlann — yes, still very much interested, and I'd like to find a way to get this into 2.1 rather than pushing it out to 3.0.

If the blocker is specifically the @FunctionalInterface binary-compatibility break, I can rework the HeaderAccessor addition so it doesn't touch that contract — e.g. keep validateHeaders(Map) as the sole abstract/functional method and add HeaderAccessor support as an additional default method that bridges to it, rather than replacing it. That should keep the change non-breaking and 2.1-compatible. Let me know if that approach works and I'll push an update.

So the @FunctionalInterface drop would be a breaking change. Let's keep it.

Let's do this instead:

1. Deprecate ServerTransportSecurityValidator
2. Introduce a new interface, ServerHttpHeaderValidator, with a void validate(HeaderAccessor headerAccessor)
3. Introduce builder methods in the transports with this new validator
4. Update the default transport validator to also implement ServerHttpHeaderValidator
5. Add static ServerHttpHeaderValidator toHttpHeaderValidator(ServerTransportSecurityValidator validator)
6. Change the builder methods in the transports that use a ServerTransportSecurityValidator to wrap the server validator into a ServerHttpHeaderValidator (and deprecate them)
7. Feed a ServerHttpHeaderValidator into the transports instead of the old validators, and use that.

How does that sound?

Hi @Kehrlann, that sounds good to me. Thanks for laying out the compatibility path clearly. I'll keep ServerTransportSecurityValidator as the deprecated functional, map-based API; introduce ServerHttpHeaderValidator; add the new transport builder methods; and adapt the deprecated builder methods through toHttpHeaderValidator(...). I'll also update the default validator and have the transports use the new validator internally. I'm working through the update now and will push it shortly.

@Kehrlann Pushed the update following the plan above:

• ServerTransportSecurityValidator — deprecated, unchanged contract (still @FunctionalInterface, still validateHeaders(Map))
• ServerHttpHeaderValidator — new interface with void validate(HeaderAccessor), plus a NOOP constant
• DefaultServerTransportSecurityValidator — now implements both interfaces; the real logic lives in validate(HeaderAccessor), and the deprecated validateHeaders(Map) bridges into it
• ServerTransportSecurityValidator.toHttpHeaderValidator(ServerTransportSecurityValidator) — static adapter wrapping an old validator as a ServerHttpHeaderValidator
• 3 servlet transports (SSE, stateless, streamable) — added httpHeaderValidator(ServerHttpHeaderValidator) builder methods; the existing securityValidator(ServerTransportSecurityValidator) methods are deprecated and now wrap via the adapter; internally the transports store and call only ServerHttpHeaderValidator

Tests: all 48 DefaultServerTransportSecurityValidatorTests and all 19 ServerTransportSecurityIntegrationTests pass. No existing caller (old or new API) should observe a behavior change.

Let me know if you'd like anything adjusted.

@Kehrlann Pushed a follow-up commit addressing all 5 review comments:

• Hoisted the anonymous HeaderAccessor in validateHeaders(Map) into a named MapHeaderAccessor nested class
• Added .filter(Objects::nonNull) before .findFirst() in that accessor
• Fixed toHttpHeaderValidator to preserve original header-name casing (was lowercasing via String::toLowerCase, which changed behavior vs. the old case-sensitive HttpServletRequestUtils#extractHeaders)
• Corrected @since tags on HeaderAccessor and HttpServletHeaderAccessor to 2.1.0

All existing tests pass (updated one test that relied on the old lowercase-key behavior). Would appreciate another look when you have a chance. Thanks!

Thanks for your contribution. Merged through 5be2fa0.