Update JacksonAutoConfiguration with safer defaults

[harish-prakash]

Should Boot disable by default FAIL_ON_UNKNOWN_PROPERTIES in the ObjectMapper configuration?

Jackson's stock configuration actually fails deserialization whenever it encounters an unknown property. The only argument against this is Postel's law which has been challenged in recent days

• RFC 7103 - Advice for Safe Handling of Malformed Messages The consequences of misinterpreting Postel's (Robustness) Law.
• RFC 3117 Postel's law counterintuitively leads to deployment problems
• Privacy Enhancing Technologies - Dropping on the Edge: Flexibility and TrafficConfirmation in Onion Routing Protocols Though this paper does not mention Postel or Robustness principle, this attack is based on the Tor networks nature to silently drop non-understandable messages.

Though RFC 3117 and PoPETS article do not talk about HTTP (Postel's law itself mainly focused on TCP) they are very good examples why unmanaged rejection is not always a good idea.

Furthermore FasterXML's Jackson team had a very good reason why not to blindly follow the law. (reference).

My question is, why would spring decide to deviate from a structured default? I understand the general concern for backward and forward compatibility, would it not be more efficient if implementations explicitly accepted unknown properties and logged them instead of Spring deciding to silently drop them?

Some may find this question intentionally begins the same way its counter-request did a few years ago. Issue #1237

[philwebb]

Every default has a trade off, but I feel like our current approach works well for most of our users. Specifically, I like the fact that the JSON I'm consuming can have additional fields added without my application breaking.

It's also very easy to change the defaults if they don't work for you by adding the following to your application.properties file:

spring.jackson.deserialization.fail-on-unknown-properties=true

[harish-prakash]

I really cannot argue with

but I feel like our current approach works well

:)