Backport deprecation warning header limits to 5.6

[orangejulius]

Hello!

In #28427, configuration options were added for the deprecation warning headers that are sent along in HTTP responses.

Please consider backporting these changes to Elasticsearch 5.6. In particular, because Node.js just released security updates that reject response headers over 8192 bytes, its likely a significant number of users of Node.js will now see issues due to those headers.

Hopefully, that will lead to them fixing the issues raised by the deprecation warnings! :)

However, in some cases, it's not feasible to fix the warnings immediately. In my case, I maintain an open source project (the Pelias geocoder), where we are currently migrating from Elasticsearch 2 to 5. We can't fix the deprecation warnings until we drop support for ES2, and we can't drop that support right away.

While there are discussions about setting a default to the number of warnings returned, even having the option to set that limit would be enough for now. I understand that setting new default config options might not be possible on older releases that are technically only getting bugfixes, and no behavior changes would be allowed.

Let me know if backporting this change is possible or if there is another solution. Thanks!

[elasticmachine]

Pinging @elastic/es-core-infra

[jasontedor]

Hi @orangejulius, thanks for your interest and raising this for discussion. I am especially appreciative that you indicate an understanding the tension here.

I understand that setting new default config options might not be possible on older releases that are technically only getting bugfixes, and no behavior changes would be allowed.

Our maintenance policy here is our guide here. We only release bug fixes to patch releases, and the 5-series is in maintenance-only mode now that the 6-series is the current major series. We avoid making enhancements to a stable branch like the 5.6 branch, so that users can rely on upgrading with minimal risk of an unstable release.