strange {"OK":{}} response on ElasticSearch curl -X GET 'http://localhost:9200'

Question

On one on my nodes in my ElasticSearch cluster I get the following strange response:

Command:

curl -X GET 'http://localhost:9200'

Response:

{"OK":{}}

Not sure what to do about this? Anyone run into this before?

UPDATE:

This is what I get when I call (I replaced IP's with xxx):

curl -XGET localhost:9200/_nodes/jvm?human\&pretty

{
  "cluster_name" : "elasticsearch",
  "nodes" : {
    "dtUV63D4RBq9JXw_o03-eg" : {
      "name" : "elasticsearch1",
      "transport_address" : "inet[xxx/xxx:9300]",
      "host" : "elasticsearch1",
      "ip" : "xxx",
      "version" : "1.3.2",
      "build" : "dee175d",
      "http_address" : "inet[/xxx:9200]",
      "jvm" : {
        "pid" : 1471,
        "version" : "1.7.0_65",
        "vm_name" : "OpenJDK 64-Bit Server VM",
        "vm_version" : "24.65-b04",
        "vm_vendor" : "Oracle Corporation",
        "start_time" : "2014-11-19T14:50:10.408Z",
        "start_time_in_millis" : 1416408610408,
        "mem" : {
          "heap_init" : "4gb",
          "heap_init_in_bytes" : 4294967296,
          "heap_max" : "3.9gb",
          "heap_max_in_bytes" : 4277534720,
          "non_heap_init" : "23.1mb",
          "non_heap_init_in_bytes" : 24313856,
          "non_heap_max" : "214mb",
          "non_heap_max_in_bytes" : 224395264,
          "direct_max" : "3.9gb",
          "direct_max_in_bytes" : 4277534720
        },
        "gc_collectors" : [ "ParNew", "ConcurrentMarkSweep" ],
        "memory_pools" : [ "Code Cache", "Par Eden Space", "Par Survivor Space", "CMS Old Gen", "CMS Perm Gen" ]
      }
    },
    "8eGVx6IGQ8qiFTc4rnaG3A" : {
      "name" : "elasticsearch2",
      "transport_address" : "inet[/xxx:9300]",
      "host" : "elasticsearch2",
      "ip" : "xxx",
      "version" : "1.3.2",
      "build" : "dee175d",
      "http_address" : "inet[/xxx:9200]",
      "jvm" : {
        "pid" : 1476,
        "version" : "1.7.0_65",
        "vm_name" : "OpenJDK 64-Bit Server VM",
        "vm_version" : "24.65-b04",
        "vm_vendor" : "Oracle Corporation",
        "start_time" : "2014-11-19T14:54:33.909Z",
        "start_time_in_millis" : 1416408873909,
        "mem" : {
          "heap_init" : "4gb",
          "heap_init_in_bytes" : 4294967296,
          "heap_max" : "3.9gb",
          "heap_max_in_bytes" : 4277534720,
          "non_heap_init" : "23.1mb",
          "non_heap_init_in_bytes" : 24313856,
          "non_heap_max" : "214mb",
          "non_heap_max_in_bytes" : 224395264,
          "direct_max" : "3.9gb",
          "direct_max_in_bytes" : 4277534720
        },
        "gc_collectors" : [ "ParNew", "ConcurrentMarkSweep" ],
        "memory_pools" : [ "Code Cache", "Par Eden Space", "Par Survivor Space", "CMS Old Gen", "CMS Perm Gen" ]
      }
    }
  }
}

Answer 1

Elasticsearch 1.3.2 alone is not capable of producing such response - there is simply no "OK" string in the production source code. So, I would guess somebody installed a plugin on this node that intercepts some calls and replaces them with this message.

One of the plugins that does that is elasticsearch-http-basic plugin, which indeed displays {"OK":{}} to unauthorized users instead of a full response. You can verify presence of this and other plugins by executing the following command on the node that gives you responses:

curl "localhost:9200/_nodes/plugins?pretty"