Expose spring.webflux.response-encoded-html-escape as a Boot Configuration Property

Summary

Once spring-projects/spring-framework#36716 is resolved, Spring Boot should expose spring.webflux.response-encoded-html-escape as a configuration property, following the exact same pattern by which spring.webflux.default-html-escape was introduced in #49791 which is implemented and introduced through both spring and spring boot by me

Background

Spring Framework PR #36400 wired defaultHtmlEscape into WebFlux across WebHttpHandlerBuilder → HttpWebHandlerAdapter → ServerWebExchange. Boot exposed that as spring.webflux.default-html-escape via #49791, which added a @Nullable Boolean defaultHtmlEscape field to WebFluxProperties and wired it into HttpHandlerAutoConfiguration via handlerBuilder.defaultHtmlEscape(properties.getDefaultHtmlEscape()).
Spring MVC's RequestContext has always had a second companion flag — responseEncodedHtmlEscape — that controls whether HtmlUtils.htmlEscape(String, String) (encoding-aware) or HtmlUtils.htmlEscape(String) (ISO-8859-1) is used when escaping is active. PR #36400 did not carry this flag over to WebFlux. the Framework issue #36716 I opened proposes completing that parity by adding responseEncodedHtmlEscape to WebHttpHandlerBuilder, HttpWebHandlerAdapter, and WebFlux RequestContext, mirroring the structure of #36400 exactly.

Requested Change

Once https://github.com/spring-projects/spring-framework/issues/36716 merges, Boot should expose:

spring.webflux.response-encoded-html-escape=true|false

When set to true, WebFlux RequestContext will call HtmlUtils.htmlEscape(String, String) with the response's character encoding — meaning UTF-8 applications escape only XML-significant characters (<, >, &, ") and leave non-ASCII characters like accented or Greek letters intact; when false or unset, HtmlUtils.htmlEscape(String) is used, which encodes all non-ASCII characters as numeric entities, a lossy default for any WebFlux application serving international content.

Dependency

This issue is blocked on spring-projects/spring-framework#36716. No Boot-side changes are needed until that lands.

Suggested Implementation

This follows the established pattern from #49791 precisely:

WebFluxProperties — add a

@Nullable Boolean responseEncodedHtmlEscape

field alongside the existing defaultHtmlEscape field, with a matching getter and setter:

/**
 * Whether response-encoded HTML escaping is enabled for the web application.
 */
private @Nullable Boolean responseEncodedHtmlEscape;

HttpHandlerAutoConfiguration — extend the existing properties != null block:

if (properties != null) {
    handlerBuilder.defaultHtmlEscape(properties.getDefaultHtmlEscape());
    handlerBuilder.responseEncodedHtmlEscape(properties.getResponseEncodedHtmlEscape()); // added
}

HttpHandlerAutoConfigurationTests — add a @ParameterizedTest / @ValueSource(booleans = { true, false }) test asserting that spring.webflux.response-encoded-html-escape propagates through the HttpWebHandlerAdapter, mirroring shouldConfigureDefaultHtmlEscape().

The wiring target on the Framework side will be WebHttpHandlerBuilder.responseEncodedHtmlEscape(Boolean), which #36716 proposes to stamp onto the exchange as ServerWebExchange.RESPONSE_ENCODED_HTML_ESCAPE_ATTRIBUTE, making it readable from WebFlux RequestContext.isResponseEncodedHtmlEscape().

I will be happy to be assigned for this once the framework change lands

Wait for spring-framework#36716 to land, then start with WebFluxProperties and HttpHandlerAutoConfiguration, following the existing defaultHtmlEscape wiring. Run HttpHandlerAutoConfigurationTests and add the parameterized propagation coverage described for response-encoded-html-escape. Done means the property binds in Boot and reaches the WebFlux handler adapter for both true and false values.