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 the DispatcherServlet (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.