# Support JSON "\_comment" name/value? **URL:** \ **Category:** Elasticsearch\ **Created:** [January 18, 2019, 4:37pm UTC](https://discuss.elastic.co/t/support-json-comment-name-value/164831 "2019-01-18T16:37:24Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![m9aertner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/m9aertner/32/39588_2.png) [@m9aertner](https://discuss.elastic.co/u/m9aertner)\ **Post date:** [January 18, 2019, 4:37pm UTC](https://discuss.elastic.co/t/support-json-comment-name-value/164831/1 "2019-01-18T16:37:25Z")
We all know that JSON syntax does not support comments, for good and bad reasons. Also, we know that in many cases, comments are really, really useful, and that it's mostly up to the _receiver_ to not do anything bad with them, like using them for processing instructions or so. Can ElasticSearch be _made lenient_ at least with respect to e.g. "\_comment":"\" pairs in its RESTful API? On recption, ElasticSearch would just _ignore_ any and all of these pairs, including their value. On JSON production, such pairs would never be produced, as today. This well-known pattern is compatible with strict JSON syntax and does not have any functional impact. It furthers, on the other hand, support for transparency and traceability which _are_ important aspects or even prerequisites for some processes, for many organizations. ---
**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\ **Post date:** [January 18, 2019, 5:43pm UTC](https://discuss.elastic.co/t/support-json-comment-name-value/164831/2 "2019-01-18T17:43:29Z")
This roughly duplicates [#30576](https://github.com/elastic/elasticsearch/issues/30576). We discussed it as a team and concluded at that time that we wouldn't do this, reasoning that: > the query language is a communication protocol between client and server and not a user interface. Ignoring `_comment` fields in documents would be a breaking change to users that currently index `_comment` fields. We try not to make breaking changes without a very good reason. We also don't really like lenience as a general rule, because it makes it all too easy to quietly do the wrong thing. The [`X-Opaque-Id` header](https://www.elastic.co/guide/en/elasticsearch/reference/6.2/tasks.html#_identifying_running_tasks) is a good way to add traceability to your Elasticsearch usage. ---
**Author:** ![m9aertner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/m9aertner/32/39588_2.png) [@m9aertner](https://discuss.elastic.co/u/m9aertner)\ **Post date:** [January 21, 2019, 8:44am UTC](https://discuss.elastic.co/t/support-json-comment-name-value/164831/3 "2019-01-21T08:44:19Z")
Thanks for your speedy reply and for mentioning the earlier issue that unfortunately I had failed to see. The `X-Opaque-Id` is a great idea (available since 6.2 as per the docs). I shall look into that for communication-level transparency. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [February 18, 2019, 8:44am UTC](https://discuss.elastic.co/t/support-json-comment-name-value/164831/4 "2019-02-18T08:44:19Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.