elastic/elasticsearch
XContentParser Behaves Differently for Stream and Byte Array
已关闭
#61,489 创建于 2020年8月24日
:Core/Infra/Core>bugTeam:Core/Infrahelp wantedtriaged
仓库指标
- 星标
- (76,700 个星标)
- PR 合并指标
- (平均合并 2天) (30 天内合并 1,000 个 PR)
描述
Optimizing BytesReference parsing in #61447 revealed a subtle bug in x-content parsing.
The following test:
public void testIncompatibleStreamTypes() throws Exception {
final Map<String, Object> map = Map.of("foo", "bar");
final BytesReference jsonBytes = BytesReference.bytes(JsonXContent.contentBuilder().map(map));
final Map<String, Object> deserialized = SmileXContent.smileXContent.createParser(
NamedXContentRegistry.EMPTY, DeprecationHandler.IGNORE_DEPRECATIONS, jsonBytes.streamInput()).map();
assertEquals(deserialized, Collections.emptyMap());
final BytesRef bytes = jsonBytes.toBytesRef();
final Map<String, Object> deserialized2 = SmileXContent.smileXContent.createParser(
NamedXContentRegistry.EMPTY, DeprecationHandler.IGNORE_DEPRECATIONS, bytes.bytes, bytes.offset, bytes.length).map(); // this throws
}
will actually pass until the last line which will throw:
com.fasterxml.jackson.core.JsonParseException: Input does not start with Smile format header (first byte = 0x7b) -- rather, it starts with '{' (plain JSON input?) -- can not parse
at [Source: (byte[])"{"foo":"bar"}"; line: -1, column: 0]
So for reading from streams, we simply read empty map when the type is off but when reading from a byte array we (in my opinion correctly) throw an exception. I think we should throw that same exception when reading from a stream of the wrong content type shouldn't we?