Content type detection for rest requests is deprecated. Specify the content type using the [Content-Type] header.

[devkr]

Please use the following questions as a guideline to help me answer
your issue/question without further inquiry. Thank you.

Which version of Elastic are you using?

[ ] elastic.v2 (for Elasticsearch 1.x)
[ ] elastic.v3 (for Elasticsearch 2.x)
[ X ] elastic.v5 (for Elasticsearch 5.x)

Please describe the expected behavior

Not seeing the following multiple times a second in Elastic Search log:
[2017-04-16T03:08:14,616][WARN ][o.e.d.r.RestController ] Content type detection for rest requests is deprecated. Specify the content type using the [Content-Type] header.

Please describe the actual behavior

Looks like Content-Type header is becoming mandatory and Elastic Search 5.3 warns that it is deprecated in the log for every bulk insert. I am not sure, but looks like bulk inserts are getting "setBodyString" in SetBody function of request.go and hence no Content-Type header is being set (as oppose to setBodyJson for example).

Any steps to reproduce the behavior?

Bulk Insert.

[olivere]

Thanks for reporting. It seems they added this section in the 5.3 documentation, which wasn't there in 5.2:

When sending requests to this endpoint the Content-Type header should be set to application/x-ndjson.

I will add that the next time I'm fixing issues.

[olivere]

I'm not seeing this error message in the tests. Can you provide a reproducible test case?

[olivere]

Oh... I see. It's in the response, not the server log:

HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: application/json; charset=UTF-8
Warning: 299 Elasticsearch-5.3.0-3adb13b "Content type detection for rest requests is deprecated. Specify the content type using the [Content-Type] header." "Tue, 18 Apr 2017 21:05:02 GMT"
...

[olivere]

Fixed in 5.0.35.

[devkr]

Thanks for the quick fix!

[mkhetan]

We want to use this fix in our code urgently. Is there a new gopkg.in olivere elastic version going to be released soon?

Thanks

[olivere]

@mkhetan It should be fixed in 5.0.35 with this commit.

[untoldone]

@olivere Documenting rather than requiring a new type seems like a breaking change that broken old clients and a lot of old code (such as https://github.com/mattbaird/elastigo). I question whether changes such as this are the correct route. Personally, it makes me want to look at other projects when I see breaking changes introduced without a significant and overwhelming reason to do so for fear that working with the upstream component will break underneath me and require more engineering.

In this particular case, I will need to:

1. hack together a solution that makes https://github.com/mattbaird/elastigo work with this header requirement... not super difficult, but not ideal
2. migrate to wholly new library
3. lock myself to an earlier version of ElasticSearch

All of this could have been avoided by not introducing this type of change or by giving a migration path (such as by deprecating the API as a whole but allowing continued use).

[olivere]

@untoldone I care a lot for breaking changes. Care to explain how adding a Content-Type for the requests from elastic to Elasticsearch, and hence do what all the official clients do, broke your code?

[untoldone]

@olivere Really sorry, I misread this thread and didn't realize this was the wrong project entirely... I'm pretty embarrassed about that. Sorry for bothering you with this and appreciate your quick reply.

For context, the client library I am using seems to have broken given ElasticSearch's behavior around content-type and I intended to open a bug on ElasticSearch itself -- i missread this thread to say "we'll document it rather than address the broken-ness" even though this thread is unrelated.