Fail requests on deprecated syntax

[nik9000]

Describe the feature:
I'd be useful to have a switch that you could set that would fail a request that uses deprecated syntax. It'd be must useful for things like creating indexes, where the deprecated settings live for a long time. I talked to some folks who started using Elasticsearch on 1.x, wanted to migrate to 2.x, but were a bit stuck because their mappings contained syntax from 0.90. They never meant to use deprecated syntax, they just did on accident.

[jpountz]

We already have index.query.parse.strict but I agree we need something that applies to the whole request and not only queries.

[jpountz]

See also #8963.

[javanna]

I think the problem is just renaming the setting that turns this on. It's already used outside of queries as far as I can remember, pretty much applied to the whole REST layer (wherever we use ParseField). Plus we should switch more things to ParseField.

[clintongormley]

The switch should upgrade anything going to the deprecated log to be an exception.

[clintongormley]

This would be particularly useful for cross-stack integration tests - it would help alert the logstash, beats, and kibana teams early on to their use of deprecated syntax.

[clintongormley]

I think we can close this now that #17687 has been merged

[javanna]

Sorry Clint, me again :) Wasn't #17687 about returning a warning header, while this issue was about failing requests completely? Is failing a request possible when it contains usage of any deprecated syntax?

[jpountz]

I was initially more in favour of failing requests, but now that I think more about it I think a warning is good enough, then the client can deal with the warnings however it wants, similarly to failed or missing shards. This way, we also don't have to support yet another request parameter, we can just send warnings all the time and let clients deal with it.

[javanna]

I am digging what you propose @jpountz , I like it. I think that some of our language clients don't expose headers though. I don't think there would be any problem other than that. Nothing needs to be enabled, you always get warnings, you just have to decide what to do with them. Sounds good to me.

[nik9000]

What about curl? I guess if sense can be made to complain appropriately on those headers we can be in good shape?

I can put together something for the rest tests and docs to fail if they see this header unless it is explicitly marked as expected if we're truly ok with just the Warnings.

Also, if we're ok with warning headers then should we just remove the strict parsing entirely? Relates to #19552

[jpountz]

I guess if sense can be made to complain appropriately on those headers we can be in good shape?

This is a great idea!!

Also, if we're ok with warning headers then should we just remove the strict parsing entirely?

I think it's worth discussing indeed...