Briefly, this error occurs when Elasticsearch receives a request with an unexpected content type in the headers. This could be due to a mismatch between the content type specified in the request and the actual content type of the data. To resolve this issue, ensure that the content type in the request headers matches the actual content type of the data. If you’re using a client library, check its documentation to ensure you’re setting the content type correctly. Also, ensure that any proxies or middleware between your client and Elasticsearch aren’t altering the headers.
This guide will help you check for common problems that cause the log ” [{}] [{}] input expected content type [{}] but read [{}] from headers; using expected one ” to appear. To understand the issues related to this log, read the explanation below about the following Elasticsearch concepts: plugin.
Log Context
Log “[{}] [{}] input expected content type [{}] but read [{}] from headers; using expected one” classname is ExecutableHttpInput.java.
We extracted the following from Elasticsearch source code for those seeking an in-depth context :
//Attempt to auto detect content type; if not set in response
contentType = responseContentType != null ? responseContentType : XContentHelper.xContentType(response.body());
} else {
contentType = input.getExpectedResponseXContentType().contentType();
if (responseContentType != contentType) {
logger.warn("[{}] [{}] input expected content type [{}] but read [{}] from headers; using expected one"; type(); ctx.id();
input.getExpectedResponseXContentType(); responseContentType);
}
}
if (contentType != null) {
