Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change Deprecated REST Handler prefix to be more granular #19377

Closed
djschny opened this issue Jul 12, 2016 · 1 comment
Closed

Change Deprecated REST Handler prefix to be more granular #19377

djschny opened this issue Jul 12, 2016 · 1 comment

Comments

@djschny
Copy link
Contributor

djschny commented Jul 12, 2016

Elasticsearch version: master (v5.0.0)

JVM version: n/a

OS version: n/a

Describe the feature:

Recently a deprecation warning response header was added as part of #17804 and //issues/17687

The prefix used is Warning: however this is not really granular enough to make it useful.

For example to really get the full benefit of this running packetbeat on Elasticsearch nodes indexing the rest requests would be ideal. Then dashboards could be built in Kibana showing the top X URL paths that have deprecations, etc. However since these are grouped under the common/generic Warning: header it is less than ideal as one would need to do a query on the word "deprecation" in the text of the header. If something like X-Elasticsearch-Deprecation was used it would make it very easy to filter and also future proofs if other non-deprecation warnings are added in the future.

@clintongormley
Copy link
Contributor

I think you're misunderstanding the purpose of the deprecation headers. Deprecation headers are intended to alert the USER that the request that they have just run uses deprecated functionality (ie it provides the context to the user). As such, the official Warning: header is perfect for the purpose.

We also have deprecation logs, which provide the SYSADMIN with information that users are using deprecated functionality (but with less context). If you wanted to make graphs out of deprecations, then consuming the deprecation logs would be the way to go.

However, making graphs out of how many different types of deprecations there are really doesn't help much. What you want to know is that there is NO use of deprecated functionality, as it will break in the next major version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants