Description
The current arrangement with our spring.http
configuration properties namespace feels a bit odd.
Currently, we have:
spring.http.log-request-details
, which enables logging for HTTP requests on theDispatcherServlet
(params and headers depending on the logging level). It also enables logging details for multipart and form HTTP requests on both server and client for WebFlux.spring.http.encoding.*
properties are configuring a character encoding Servlet filter for Servlet applications, and also configuring the MVC HTTP message readers (both server and client).
This namespace is mixing client, server, Servlet, MVC and webflux concerns, making it hard to understand what's being configured.
Proposal
We could move spring.http.encoding.*
to server.servlet.encoding.*
, making it obvious that it's mostly for server and Servlet only. Right now we are applying that preference to the String HTTP message reader for RestTemplate
and MVC server, but since we are UTF-8 by default, I'm wondering if creating an dedicated property is really worth it.
We could also move spring.http.log-request-details
to spring.mvc.log-request-details
, since most properties in that namespace already apply to the DispatcherServlet
.
For the reactive codecs support (client and server), we're mostly targeting classes in org.springframework.http.codec
for Spring Framework (Spring Core and Web). I think a spring.http.codec
namespace is a good choice and aligns with a possible implementation for both spring.http.codec.log-request-details
and the upcoming spring.http.codec.max-in-memory-size
.