Http compression enabled but response not compressed

Elastic Stack Elasticsearch
1

I set http.compression: true and http.compression_level: 3 in the elasticsearch.yml file of each node in the cluster.
Viewing the _nodes/settings?pretty shows that it is indeed enabled.
The problem is that the response from elastic is never actually compressed (Accept-Encoding header is being sent with gzip, deflate).
Why are is the response never compressed? Am I missing a setting?

2

For clarification responses are compressed when I test locally on my Windows 10 machine with a single instance running. However on a two node cluster with the nodes running Ubuntu 1604 the responses never seem to be compressed. I've tested this with two different clusters, one cluster with nodes running 5.6.2 and one cluster with the nodes running 5.5.5 installed following this guide.
None of these clusters sent compressed responses. What could be the cause of this? How can this be troubleshooted?

3

I tried setting the network.host on my machine to my local ip rather than localhost and responses stopped being compressed. Why is this?

4

It seems that elastic search will not compress responses if the host is anything other than localhost. Tested with 5.6.0. Not sure why this is.

5

Could you tell how you discovered that (how do you know it's compressed or not)?

6

The Content-Encoding header is sent as a response when calling /_nodes/settings?pretty to the localhost host, whilst when performing the same request to my local ip it is not. Also the content-length is nearly three times smaller when performing the request to the localhost host,

7

Great. Could you open an issue and write all those details including the content-length values that you have seen in both cases?

8

Done

9

Closing this thread. As you wrote on the issue you are actually using a 3rd party tool which does not ask for compression on remote hosts but only on localhost:

It indeed compresses on hosts other than localhost when issuing the requests with curl, however when using postman or a web browser it does not. Not really sure what this could be caused by.

@tanguy ran a test which shows that everything is normal as soon as the client ask for it:

Quick test I did on 5.6.2:

$ cat config/elasticsearch.yml | grep network
network.host: ["localhost","127.0.0.1","192.168.1.15"]

Now testing with curl with no Accept-Encoding header on http://localhost:9200, http://127.0.0.1:9200, http://192.168.1.15:9200 and http://laptop:9200 all return the same response headers:

curl -v -H 'Content-Type: application/json' -XGET 'http://localhost:9200/_nodes/settings?pretty&filter_path=cluster_name' 

* Connected to localhost (127.0.0.1) port 9200 (#0)
> GET /_nodes/settings?pretty&filter_path=cluster_name HTTP/1.1
> Host: localhost:9200
> User-Agent: curl/7.52.1
> Accept: */*
> Content-Type: application/json

< HTTP/1.1 200 OK
< content-type: application/json; charset=UTF-8
< content-length: 39
< 
{
  "cluster_name" : "elasticsearch"
}

The test but with Accept-Encoding: gzip header returns:

curl -v -H 'Content-Type: application/json' -H 'Accept-Encoding: gzip' -XGET 'http://localhost:9200/_nodes/settings?pretty&filter_path=cluster_name'

* Connected to localhost (127.0.0.1) port 9200 (#0)
> GET /_nodes/settings?pretty&filter_path=cluster_name HTTP/1.1
> Host: localhost:9200
> User-Agent: curl/7.52.1
> Accept: */*
> Content-Type: application/json
> Accept-Encoding: gzip

< HTTP/1.1 200 OK
< content-type: application/json; charset=UTF-8
< content-encoding: gzip
< content-length: 65
< 
��RPPJ�)-.I-��K�MUR�RPJ�I,.�L.NM,J�P�������m,'%

I have the same result if I use http://127.0.0.1:9200, http://192.168.1.15:9200 and http://laptop:9200 and I think this is the expected behaviour.

10

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.