Support application-wide defaultHtmlEscape setting in WebFlux

[husseinvr97]

Overview

Applications migrating from Spring MVC to WebFlux lose the ability to configure HTML escaping globally, creating a consistency and potential security gap.

In the servlet stack, RequestContext reads this setting cleanly from web.xml:

spring-framework/spring-webmvc/src/main/java/org/springframework/web/servlet/support/RequestContext.java

Lines 224 to 226 in 0676c95

	// Determine default HTML escape setting from the "defaultHtmlEscape"
	// context-param in web.xml, if any.
	this.defaultHtmlEscape = WebUtils.getDefaultHtmlEscape(this.webApplicationContext.getServletContext());

In the reactive stack, the equivalent is simply never implemented:

spring-framework/spring-webflux/src/main/java/org/springframework/web/reactive/result/view/RequestContext.java

Line 97 in 0676c95

this.defaultHtmlEscape = null; // TODO

spring-framework/spring-webflux/src/main/java/org/springframework/web/reactive/result/view/RequestContext.java

Lines 150 to 157 in 0676c95

	/**
	* (De)activate default HTML escaping for messages and errors, for the scope
	* of this RequestContext.
	* <p>TODO: currently no application-wide setting ...
	*/
	public void setDefaultHtmlEscape(boolean defaultHtmlEscape) {
	this.defaultHtmlEscape = defaultHtmlEscape;
	}

Those TODOs have existed since the reactive RequestContext was introduced in 5.0 M4 (2016).

Why this matters

• Migration consistency: MVC apps migrating to WebFlux expect feature parity on this setting
• Security: Global HTML escaping enforcement prevents accidental XSS exposure

Proposed solution

Add property-driven configuration for reactive applications:

propertiesspring.web.defaultHtmlEscape=true

this.defaultHtmlEscape = environment.getProperty( "spring.web.defaultHtmlEscape", Boolean.class );

Note: The MessageSource parameter already passed to the RequestContext constructor is in practice an ApplicationContext instance, which provides direct access to Environment. This means the fix requires no public API changes — just reading the property at initialization time from the already-available context, falling back to null to preserve current behavior.

I will be happy to submit a PR if this direction makes sense.

[rstoyanchev]

Thanks for bringing this up. We need to fix that indeed.

We can make it configurable programmatically in Spring Framework. The pattern for WebFlux is a config option on WebHttpHandlerBuilder that's then passed on HttpWebHandlerAdapter, and eventually set on ServerWebExchange. For this property, we can probably just set a well-known exchange attribute.

A property can be exposed in Spring Boot where there is an established hierarchy of properties. At the level of Spring Framework we rarely use properties. It's usually applications checking properties, e.g. via @Value.

Let me know if you would like to submit a PR for the Spring Framework changes.

[husseinvr97]

Thanks for the quick response @rstoyanchev and for the clear direction!
Yes, I'd love to submit a PR for the Spring Framework changes.
If I understand correctly, the approach would be:

Add a defaultHtmlEscape option to WebHttpHandlerBuilder
Pass it through to HttpWebHandlerAdapter
Stamp it as a well-known attribute on ServerWebExchange for each request
Have RequestContext read it from the exchange instead of leaving it as null

I'll get started on it. Thanks again for the guidance!