Closed
Description
ElasticSearch seems to advertise HTTP pipelining support by using HTTP 1/1 and not supplying a Connection-header in the response, but fails to deliver on the promises of responding to the requests in the same order they are sent, which means that clients might get the response from an unexpected request.
Example reproduction:
It sometimes works es expected
$ printf "GET /_nodes HTTP/1.1\r\n\r\nGET / HTTP/1.1\r\n\r\n" | nc -i 1 127.0.0.1 9200
HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
Content-Length: 222
{"ok":true,"cluster_name":"elasticsearch","nodes":{"MVf7UrJJRyaOJj35MAdODg":{"name":"Caiera","transport_address":"inet[/10.0.0.6:9300] ","hostname":"machine.local","version":"0.20.4","http_address":"inet[/10.0.0.6:9200]"}}}HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
Content-Length: 169
{
"ok" : true,
"status" : 200,
"name" : "Caiera",
"version" : {
"number" : "0.20.4",
"snapshot_build" : false
},
"tagline" : "You Know, for Search"
}
But sometimes, given the exact same request, changes the order of the responses:
$ printf "GET /_nodes HTTP/1.1\r\n\r\nGET / HTTP/1.1\r\n\r\n" | nc -i 1 127.0.0.1 9200
HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
Content-Length: 169
{
"ok" : true,
"status" : 200,
"name" : "Caiera",
"version" : {
"number" : "0.20.4",
"snapshot_build" : false
},
"tagline" : "You Know, for Search"
}HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
Content-Length: 222
{"ok":true,"cluster_name":"elasticsearch","nodes":{"MVf7UrJJRyaOJj35MAdODg":{"name":"Caiera","transport_address":"inet[/10.0.0.6:9300] ","hostname":"machine.local","version":"0.20.4","http_address":"inet[/10.0.0.6:9200]"}}}