Set content-type header to application/json

[ycombinator]

Resolves #7963

[spalger]

We need to assign this based on the actual content type, as of now there are two content types possible, application/json for standard bodies and text/plain for newline-delimited json bodies for APIs like bulk

[ycombinator]

Ah yes, good catch re: bulk. Will fix.

[ycombinator]

@spalger There is (sort of) an edge case with this check. Consider the following valid _bulk API request:

POST /foo/bar/_bulk
{ "delete": { "_id": "1" } }

The content-type for this request will be set to application/json, not text/plain as it would be for multiline _bulk requests.

I'm okay with this because the body is infact valid JSON in this case. Also, Elasticsearch handles this request with its content type as application/json. Still, I wanted to point it out in case you feel differently.

[spalger]

Another edge case is when users are not using the bulk API but submit slightly invalid JSON (like { name: 'val' }). Elasticsearch will accept it, but a proxy or third party would likely fail to parse it.

Ultimately though elasticsearch doesn't consider the content-type at all, which is why we didn't bother with this to begin with. The only time we should set send Content-Type: application/json is when we think the body is in fact valid JSON, so this works for me.

[ycombinator]

I am testing this PR with the following requests in Console:

# Does not set Content-Type
GET _cat/indices

# Sets Content-Type to "application/json"
POST _analyze
{
  "text": "foo bar"
}

# Sets Content-Type to "text/plain"
POST /foo/bar/_bulk
{ "index": { "_id": "1" } }
{ "foo": "bar" }
{ "delete": { "_id": "1" } }

# Edge case (sort of): Sets Content-Type to "application/json"
POST /foo/bar/_bulk
{ "delete": { "_id": "1" } }

[spalger]

LGTM