Http server does not handle multiple requests correctly when pipeling disabled

[Tim-Brooks]

It appears to me that we do not have protections to ensure that multiple http requests over a single connection are handled correctly when http pipelining is not enabled.

Essentially if a client sends multiple requests, we will receive those requests, parse them, and dispatch them to other threads for handling. Without the pipelining enabled, the first request to be handled will be the first response written back to the channel. This leads to out of order responses.

I'm not immediately sure what the fix is. We could always enable pipelining. Or maybe the server should send a something like a 501 if it receives a requests before the initial response has been returned?

[elasticmachine]

Pinging @elastic/es-core-infra

[ghost]

Hi, can i fork and try playing with this issue???

[jasontedor]

When HTTP pipelining is disabled, a client that is sending a request before it has received the response for a previous request is misbehaving with respect to Elasticsearch (I am not saying they are misbehaving with respect to the HTTP/1.1 specification).

We could always enable pipelining.

The default is for it to be enabled, and I agree the germane question is whether or not we should remove the ability for it to be disabled.

From the HTTP/1.1 specification:

A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received.

With this, I lean towards saying that we remove the ability to disable pipelining (i.e., pipelining is always enabled).

[Tim-Brooks]

The default is for it to be enabled, and I agree the germane question is whether or not we should remove the ability for it to be disabled.

Right. I worded it poorly, but removing the option for pipelining to be disabled is what I was suggesting.

With this, I lean towards saying that we remove the ability to disable pipelining (i.e., pipelining is always enabled).

I agree. Users could still set http.pipelining.max_events to a lower number if they want to limit inflight requests.

[jasontedor]

@tbrooks8 Let us move forward with removing the ability to disable pipelining. We can deprecate in 6.x.

[Tim-Brooks]

These tasks need to be completed:

• Remove the http.pipelining setting. All http modules must support pipelining
• Cleanup all the references to enabled or disabled pipelining the integration test code
• Deprecate in 6.x

[Tim-Brooks]

Closing this as pipelining support is now mandator in 7.0 and the setting is deprecated in 6.x.