_settings API fails to determine source format

[popravich]

Elasticsearch version: 2.1.2

JVM version: openjdk 8u91-b14-0ubuntu4~15.10.1

OS version: ubuntu 15.10

Description of the problem including expected versus actual behavior:

Trying to put settings through REST API using YAML format fails with exception json_parse_exception.

Steps to reproduce:

1. simply run the following

curl -XPUT localhost:9200/some-index/_settings?pretty --data-binary '

---
analysis:
  analyzer:
    default: { type: keyword }
'

I believe that problem is here https://github.com/elastic/elasticsearch/blob/master/core/src/main/java/org/elasticsearch/common/settings/loader/SettingsLoaderFactory.java#L73-L79

PS: it made my day when I saw this lines, you guys are the best)

[jasontedor]

The Elasticsearch REST APIs are JSON-based, so you can and should just submit the request here as a JSON request, submitting as YAML is not going to work here because of that detection.

[bleskes]

actually we do support YAML as a body. The reason why it doesn't work is that the initial space in your body throws off the auto detection. This works:

boaz$ curl -XPUT localhost:9200/some-index/_settings?pretty --data-binary '---
analysis:
  analyzer:
    default: { type: keyword }
'

Sadly we currently do not listen to the content type http header. This is discussed in #19388 . The result of that issue will also determine whether we want to be friendlier to yaml skip leading whitespace (as we now do for JSON), which I think we can keep this one closed.

[popravich]

Hi,
As just mentioned in related issue, YAML parser can parse JSON, so it can be used as one.

Your example doesn't work as well, it fails because of SettingsLoaderFactory.loaderFromSource

[bleskes]

Your example doesn't work as well

bleh, you are right. I checked the cluster settings action, not the index one (where my analysis is correct). On the index level you are correct, it doesn't work now and the JSON detection borks the yaml one. I'm opening it again, but it will have to wait for #19388 to see what is the best course of action.

[clintongormley]

Content detection is just flawed. We should remove it as per #19388. Current content detection would also break SMILE or CBOR if it happened to contain a { character

[bleskes]

@clintongormley the content detection on the setting part is indeed broken, but in other places (like the indexing code) we look at byte markers at the beginning of the request, so that doesn't happen. I'll respond to the removal part on the other ticket.