You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Since the codecs configuration is common to reactive HTTP server/client, but also other use cases like RSocket - we should have spring.codec instead of spring.http.codec.
Also, CodecsAutoConfiguration is in org.springframework.boot.autoconfigure.http.codec and we probably should move it to org.springframework.boot.autoconfigure.codec.
bclozel
changed the title
Rework "spring.http.*" configuration properties namespace
Move spring.http.* configuration properties namespace
Jan 14, 2020
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.*
toserver.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 forRestTemplate
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
tospring.mvc.log-request-details
, since most properties in that namespace already apply to theDispatcherServlet
.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 aspring.http.codec
namespace is a good choice and aligns with a possible implementation for bothspring.http.codec.log-request-details
and the upcomingspring.http.codec.max-in-memory-size
.The text was updated successfully, but these errors were encountered: