I'm developing a web app with Elasticsearch (1.7.1) on the back-end protected by Apache (2.4) running as a reverse proxy and the Elasticsearch angularJS module (6.1.0) providing connectivity for my angularJS (1.4.4) app. My server runs Windows 2012 R2 Datacenter and is subject to various policies and firewalls over which I have limited control. My users are sometimes compelled to run older versions of IE or Firefox which do not seem to like CORS even a little bit.
When my app opens a connection to Elasticsearch, the first thing it does is sniff for other nodes in the cluster. By default each node returns its IP address, which is bad, because it avoids my Apache reverse proxy. In order to keep using my reverse proxy, I tried setting:
http.publish_host: "my.server.domain.name/proxy_location" http.publish_port: 80
in the elasticsearch.yml file. This (and many variations involving protocols and slashes) causes Elasticsearch to fail on startup. The only thing that allows Elasticsearch to start is using:
http.publish_host: "my.server.domain.name" http.publish_port: 80
which isn't great because it doesn't include my proxy location. But, as it turns out, this doesn't even work a little bit, because when my client sniffs now it gets my server name and IP address separated by a slash (e.g. "my.server.domain.name/126.96.36.199") which seems all kinds of crazy to me.
Is this intended behavior, or is this a bug? My work around right now is to add a line that fixes the host name and tacks on my proxy location inside the sniff function of the Elasticsearch angularJS library, which is less than ideal both because the problem isn't really in the angularJS library, and also for all the normal reasons that changing 3rd party library code is less than ideal.