No need to create/reopen, I'm going to punt that in as soon as azure passed
G On Fri, Nov 28, 2025 at 4:47 PM Gyula Komlossi <[email protected]> wrote: > Thanks Gabor, I created a PR for it: > https://github.com/apache/flink/pull/27284 > If I understand correctly, there is no need for a new ticket or > reopening the old one for this. > > On Thu, Nov 27, 2025 at 6:33 PM Gabor Somogyi <[email protected]> > wrote: > > > > 1.20 is an LTS version so go on. > > > > G > > > > > > On Thu, Nov 27, 2025, 18:00 Gyula Komlossi <[email protected]> wrote: > >> > >> While trying to make the REST endpoints on my 1.20 Flink environment > >> work with SSL, I discovered that the 0.0.0.0 bind-address solution > >> won't work in this release. > >> > >> It is because in YarnEntrypointUtils, the bind address is overwritten > >> with the hostname, before it was used for creating the endpoint :) > >> > https://github.com/apache/flink/blob/release-1.20/flink-yarn/src/main/java/org/apache/flink/yarn/entrypoint/YarnEntrypointUtils.java#L68 > >> > >> This commit should be cherry-picked to release-1.20. if we want to make > it work: > >> > https://github.com/apache/flink/commit/b138d47adbed9fc1e5a73cebf649530bc5b89e6e > >> > >> Do you think it's worth a Jira and the effort? Will there be more 1.20 > >> bugfix releases in the future? > >> > >> Thanks, > >> Gyula > >> > >> On Thu, Nov 27, 2025 at 9:51 AM Gyula Komlossi <[email protected]> > wrote: > >> > > >> > Hi Gabor, > >> > > >> > Thanks for the quick response. I was wondering how a third config > >> > parameter cloud be avoided. There are two already (rest.address and > >> > rest.bind-address) and a third one would make confusion, but I > >> > understand, the existing behavior shouldn't be changed. > >> > Also the rest.address is supposed to be "The address that should be > >> > used by clients to connect to the server". Just like with the Kafka > >> > advertised listeners. > >> > > >> > For my testing I just added an extra condition to this: > >> > if (bindAddress.getAddress().isAnyLocalAddress() || isHttpsEnabled()) > { > >> > advertisedAddress = this.restAddress; > >> > } else { > >> > advertisedAddress = bindAddress.getAddress().getHostAddress(); > >> > } > >> > but it's far from ideal, it's just a workaround for now :) > >> > > >> > So I don't have a real alternative for this.. > >> > > >> > Best, > >> > Gyula > >> > > >> > On Thu, Nov 27, 2025 at 9:04 AM Gabor Somogyi < > [email protected]> wrote: > >> > > > >> > > BTW if you have any alternative way just share it either in the > jira or in PR 🙂 > >> > > > >> > > On Thu, Nov 27, 2025 at 9:02 AM Gabor Somogyi < > [email protected]> wrote: > >> > >> > >> > >> Hi Gyula, > >> > >> > >> > >> We've discussed the issue but no PR available yet. > >> > >> Feel free and cc me if you have time... > >> > >> > >> > >> BR, > >> > >> G > >> > >> > >> > >> > >> > >> On Thu, Nov 27, 2025 at 8:52 AM Gyula Komlossi < > [email protected]> wrote: > >> > >>> > >> > >>> Hi Yaroslav, Gabor, > >> > >>> > >> > >>> I just ran into this issue, when tried to configure SSL for the > REST endpoint. I'm wondering what the preferred approach is with HTTPS on > this REST endpoint or if there is any code change in progress. > >> > >>> Have you been able to solve this one way or another, or started > preparing a code change for it? > >> > >>> > >> > >>> I was able to make this work with a small code change in the > RestServerEndpoint class to use the rest.address as the advertisedAddress > with HTTPS, but I’m looking forward to the official improvement. > >> > >>> Thank you both for taking care of this! > >> > >>> > >> > >>> Best, > >> > >>> Gyula > >> > >>> > >> > >>> > >> > >>> On 2025/08/19 20:34:06 Yaroslav Chernysh wrote: > >> > >>> > https://issues.apache.org/jira/browse/FLINK-38269 > >> > >>> > > >> > >>> > On 2025/08/19 18:58:59 Gabor Somogyi wrote: > >> > >>> > > You can file a jira and open a PR too so feel free. > >> > >>> > > > >> > >>> > > G > >> > >>> > > > >> > >>> > > On Tue, Aug 19, 2025, 19:51 Yaroslav Chernysh < > [email protected]> wrote: > >> > >>> > > > >> > >>> > > > Hi Gabor, > >> > >>> > > > > >> > >>> > > > > >> > >>> > > > Just to avoid any misunderstanding, I've been waiting for > the ticket > >> > >>> > > > from you. I assumed that you were going to do it. Please > let me know if > >> > >>> > > > I got you wrong and I should create it myself. > >> > >>> > > > > >> > >>> > > > > >> > >>> > > > Best regards, > >> > >>> > > > > >> > >>> > > > Yaroslav > >> > >>> > > > > >> > >>> > > > > >> > >>> > > > On 2025/08/18 14:07:51 Gabor Somogyi wrote: > >> > >>> > > > > Yeah, please read the how to contribute guide if you > haven't done > >> > >>> > > > already. > >> > >>> > > > > > >> > >>> > > > > G > >> > >>> > > > > > >> > >>> > > > > On Mon, Aug 18, 2025 at 4:00 PM Yaroslav Chernysh < > [email protected]> > >> > >>> > > > > wrote: > >> > >>> > > > > > >> > >>> > > > > > Hi Gabor, > >> > >>> > > > > > > >> > >>> > > > > > > >> > >>> > > > > > Thanks, let's add a new option then to make advertised > address > >> > >>> > > > > > configurable and document the default behavior. Would > you mind > >> > >>> > filing > >> > >>> > > > a > >> > >>> > > > > > ticket for that? > >> > >>> > > > > > > >> > >>> > > > > > > >> > >>> > > > > > Regards, > >> > >>> > > > > > > >> > >>> > > > > > Yaroslav > >> > >>> > > > > > > >> > >>> > > > > > > >> > >>> > > > > > On 2025/08/18 13:41:54 Gabor Somogyi wrote: > >> > >>> > > > > > > Hi Yaroslav, > >> > >>> > > > > > > > >> > >>> > > > > > > Having a config option to advertise something else > is what I can > >> > >>> > > > > > support. > >> > >>> > > > > > > Needless to say the actual behavior would remain as > default. > >> > >>> > > > > > > > >> > >>> > > > > > > G > >> > >>> > > > > > > > >> > >>> > > > > > > > >> > >>> > > > > > > On Mon, Aug 18, 2025 at 3:28 PM Yaroslav Chernysh > >> > >>> > <[email protected]> > >> > >>> > > > > > > wrote: > >> > >>> > > > > > > > >> > >>> > > > > > > > Hi Gabor, > >> > >>> > > > > > > > > >> > >>> > > > > > > > I got your point on using `getHostName()`. Thank > you for such a > >> > >>> > > > > > detailed > >> > >>> > > > > > > > explanation. > >> > >>> > > > > > > > > >> > >>> > > > > > > > What do you think about advertising rest.address > instead? In > >> > >>> > > > case of > >> > >>> > > > > > > > YARN (at least on my environment), this is already > set by YARN > >> > >>> > > > to a NM > >> > >>> > > > > > > > hostname, so rDNS would be avoided. > >> > >>> > > > > > > > > >> > >>> > > > > > > > Thanks, > >> > >>> > > > > > > > > >> > >>> > > > > > > > Yaroslav > >> > >>> > > > > > > > > >> > >>> > > > > > > > > >> > >>> > > > > > > > On 2025/08/15 21:12:58 Gabor Somogyi wrote: > >> > >>> > > > > > > > > Hi Yaroslav, > >> > >>> > > > > > > > > > >> > >>> > > > > > > > > Thanks for your efforts in finding out all the > details. > >> > >>> > > > > > > > > > >> > >>> > > > > > > > > I think making `getHostName` possible with a > config + some > >> > >>> > > > > > additional > >> > >>> > > > > > > > > warnings in the documentation can be considered. > >> > >>> > > > > > > > > You need to evaluate your security standards but > you win > >> > >>> > > > something > >> > >>> > > > > > on > >> > >>> > > > > > > > one > >> > >>> > > > > > > > > side and introduce new attack vector on the > other side. > >> > >>> > > > > > > > > > >> > >>> > > > > > > > > I would write something similar in the > documentation, and > >> > >>> > I also > >> > >>> > > > > > suggest > >> > >>> > > > > > > > > you consider these for your own situation as > well: > >> > >>> > > > > > > > > - rDNS is not trustworthy for security decisions. > >> > >>> > Attackers with > >> > >>> > > > > > control > >> > >>> > > > > > > > > over PTR (or via poisoning/misconfig) can return > arbitrary > >> > >>> > > > names. > >> > >>> > > > > > > > > MITRE tracks this as CWE-350 [1] (Reliance on > Reverse DNS for > >> > >>> > > > > > > > Security). If > >> > >>> > > > > > > > > you base TLS host checks on rDNS, it’s > bypassable. > >> > >>> > > > > > > > > - Slow or failing DNS causes blocking delays > (seconds) in JVM > >> > >>> > > > > > lookups. > >> > >>> > > > > > > > > OpenJDK issues document repeated timeouts and > lack of > >> > >>> > > > > > > > > effective caching paths for some rDNS calls. > Putting rDNS in > >> > >>> > > > > > critical > >> > >>> > > > > > > > paths > >> > >>> > > > > > > > > (TLS, handshake, request handling) can amplify > random > >> > >>> > outages. > >> > >>> > > > > > > > > > >> > >>> > > > > > > > > All in all I'm not yet convinced that this issue > appears in > >> > >>> > > > other > >> > >>> > > > > > > > trending > >> > >>> > > > > > > > > environments like k8s. > >> > >>> > > > > > > > > Adding this together with the mentioned risks I > personally > >> > >>> > > > wouldn't > >> > >>> > > > > > > > merge > >> > >>> > > > > > > > > it to the main repo. > >> > >>> > > > > > > > > > >> > >>> > > > > > > > > BR, > >> > >>> > > > > > > > > G > >> > >>> > > > > > > > > > >> > >>> > > > > > > > > [1] > https://cwe.mitre.org/data/definitions/350.html > >> > >>> > > > > > > > > > >> > >>> > > > > > > > > > >> > >>> > > > > > > > > On Fri, Aug 15, 2025 at 7:44 PM Yaroslav Chernysh > >> > >>> > > > <[email protected]> > >> > >>> > > > > > > > > wrote: > >> > >>> > > > > > > > > > >> > >>> > > > > > > > > > Hi Gobor, > >> > >>> > > > > > > > > > > >> > >>> > > > > > > > > > Thank you for such a quick response, I > appreciate it. > >> > >>> > > > > > > > > > > >> > >>> > > > > > > > > > Actually, I'm not very good at all this > security and > >> > >>> > > > networking > >> > >>> > > > > > > > stuff, so > >> > >>> > > > > > > > > > I apologize in advance if I'm wrong in some > statement. > >> > >>> > > > > > > > > > > >> > >>> > > > > > > > > > > Does YARN containers share the host’s > network in your > >> > >>> > case? > >> > >>> > > > > > > > > > > >> > >>> > > > > > > > > > Yes, it does. And as far as I have researched, > it > >> > >>> > always does, > >> > >>> > > > > > > > possibly > >> > >>> > > > > > > > > > only unless you have configured YARN to use > Docker > >> > >>> > containers > >> > >>> > > > > > > > > > > >> > >>> > > > > > > > < > >> > >>> > > > > > > > > >> > >>> > > > > > > >> > >>> > > > > > > >> > >>> > > > > >> > >>> > > > > >> > >>> > > https://hadoop.apache.org/docs/r3.4.1/hadoop-yarn/hadoop-yarn-site/DockerContainers.html > >> > >>> > > > > > > > >, > >> > >>> > > > > > > > > > which is definitely not my case. I have also > done some > >> > >>> > > > testing on > >> > >>> > > > > > > > my node, > >> > >>> > > > > > > > > > which has 2 IP addresses: > >> > >>> > > > > > > > > > > >> > >>> > > > > > > > > > - With default rest.bind-address (set by YARN > to Node > >> > >>> > > > Manager's > >> > >>> > > > > > > > hostname), > >> > >>> > > > > > > > > > the only IP address that opens a port is the > one that NM > >> > >>> > > > > > hostname is > >> > >>> > > > > > > > > > resolved to. The other one (not sure where it > comes from, > >> > >>> > > > this is > >> > >>> > > > > > a > >> > >>> > > > > > > > VM) > >> > >>> > > > > > > > > > remains closed > >> > >>> > > > > > > > > > > >> > >>> > > > > > > > > > - With rest.bind-address set to 0.0.0.0, the > port is > >> > >>> > open and > >> > >>> > > > > > > > accessible > >> > >>> > > > > > > > > > via both IP addresses > >> > >>> > > > > > > > > > > >> > >>> > > > > > > > > > > However if you have a single IP then using > 0.0.0.0 and > >> > >>> > > > > > binding it to > >> > >>> > > > > > > > > > lo + eth0 is something what I wouldn't worry > about. > >> > >>> > > > > > > > > > > >> > >>> > > > > > > > > > I got the point and basically I agree here, > but I'm not > >> > >>> > > > sure how > >> > >>> > > > > > > > > > future-proof this approach is. How probable is > a > >> > >>> > scenario in > >> > >>> > > > > > which the > >> > >>> > > > > > > > > > environment (single IP node) is changed (to a > multi-homed > >> > >>> > > > > > node), but > >> > >>> > > > > > > > > > unchanged configuration (still listening on > 0.0.0.0) > >> > >>> > now leads > >> > >>> > > > > > to an > >> > >>> > > > > > > > > > excessive network exposure? Either way, that's > not my case. > >> > >>> > > > And I > >> > >>> > > > > > > > think > >> > >>> > > > > > > > > > this is not restricted to YARN too: binding to > all > >> > >>> > > > interfaces in > >> > >>> > > > > > > > Standalone > >> > >>> > > > > > > > > > deployment might be too excessive as well. > >> > >>> > > > > > > > > > > >> > >>> > > > > > > > > > > but you still have control on firewall, > right? > >> > >>> > > > > > > > > > > >> > >>> > > > > > > > > > Probably yes (saying for an average user). > This would > >> > >>> > probably > >> > >>> > > > > > > > cover the > >> > >>> > > > > > > > > > excessive binding leak, however only at the > firewall level > >> > >>> > > > and not > >> > >>> > > > > > > > at the > >> > >>> > > > > > > > > > "core". This adds a dependency on firewall. > I'm not saying > >> > >>> > > > it's > >> > >>> > > > > > > > bad, but > >> > >>> > > > > > > > > > rather that using the defense-in-depth > approach and > >> > >>> > doing both > >> > >>> > > > > > limited > >> > >>> > > > > > > > > > binding and adding firewall would be even > better than > >> > >>> > > > relying on > >> > >>> > > > > > > > firewall > >> > >>> > > > > > > > > > only. > >> > >>> > > > > > > > > > > >> > >>> > > > > > > > > > I hope all the above proves the point that > even with good > >> > >>> > > > enough > >> > >>> > > > > > > > > > environment (number of IP address + firewall) > it still does > >> > >>> > > > make > >> > >>> > > > > > > > sense to > >> > >>> > > > > > > > > > restrict the binding. At least that's how I > see this, > >> > >>> > please > >> > >>> > > > > > > > correct me if > >> > >>> > > > > > > > > > I'm wrong. > >> > >>> > > > > > > > > > > >> > >>> > > > > > > > > > > introduce reverse DNS lookup as a must have > feature > >> > >>> > > > > > > > > > > >> > >>> > > > > > > > > > Could we make it optional and disabled by > default? > >> > >>> > > > > > > > > > > >> > >>> > > > > > > > > > Thanks, > >> > >>> > > > > > > > > > > >> > >>> > > > > > > > > > Yaroslav > >> > >>> > > > > > > > > > > >> > >>> > > > > > > > > > On 2025/08/14 21:32:40 Gabor Somogyi wrote: > >> > >>> > > > > > > > > > > Hi Yaroslav, > >> > >>> > > > > > > > > > > > >> > >>> > > > > > > > > > > First of all I would like to understand why > you think > >> > >>> > > > binding to > >> > >>> > > > > > > > 0.0.0.0 > >> > >>> > > > > > > > > > is > >> > >>> > > > > > > > > > > less secure in your case. Correct me if I'm > wrong: > >> > >>> > > > > > > > > > > Does YARN containers share the host’s > network in your > >> > >>> > > > case? On a > >> > >>> > > > > > > > > > > multi-homed node, 0.0.0.0 exposes on every > host > >> > >>> > interface, > >> > >>> > > > > > > > > > > which can be less secure than binding to a > specific host > >> > >>> > > > IP. So > >> > >>> > > > > > > > this case > >> > >>> > > > > > > > > > > pinning can matter. > >> > >>> > > > > > > > > > > > >> > >>> > > > > > > > > > > However if you have a single IP then using > 0.0.0.0 and > >> > >>> > > > binding > >> > >>> > > > > > it > >> > >>> > > > > > > > to lo + > >> > >>> > > > > > > > > > > eth0 is something what I wouldn't worry > about. > >> > >>> > > > > > > > > > > Like a "normal" kubernetes pod (default > networking, > >> > >>> > single > >> > >>> > > > > > > > interface, no > >> > >>> > > > > > > > > > > hostNetwork) has no such issue. > >> > >>> > > > > > > > > > > > >> > >>> > > > > > > > > > > As a general remark. Let's say you expose > the REST > >> > >>> > endpoint > >> > >>> > > > > > on 2 IP > >> > >>> > > > > > > > > > > addresses but you still have control on > firewall, right? > >> > >>> > > > > > > > > > > > >> > >>> > > > > > > > > > > The main reason why I'm asking these > questions is because > >> > >>> > > > using > >> > >>> > > > > > > > > > > `getHostName` would introduce reverse DNS > lookup as a > >> > >>> > > > must have > >> > >>> > > > > > > > feature. > >> > >>> > > > > > > > > > > That could cause quite some turbulences at > heavy users by > >> > >>> > > > > > additional > >> > >>> > > > > > > > > > > traffic, PTR records can be wrong or > spoofed, etc... > >> > >>> > > > > > > > > > > > >> > >>> > > > > > > > > > > BR, > >> > >>> > > > > > > > > > > G > >> > >>> > > > > > > > > > > > >> > >>> > > > > > > > > > > > >> > >>> > > > > > > > > > > On Thu, Aug 14, 2025 at 8:13 PM Yaroslav > Chernysh > >> > >>> > > > > > <[email protected]> > >> > >>> > > > > > > > > > <[email protected]> > >> > >>> > > > > > > > > > > wrote: > >> > >>> > > > > > > > > > > > >> > >>> > > > > > > > > > > > Hi Flink community, > >> > >>> > > > > > > > > > > > > >> > >>> > > > > > > > > > > > Is there a particular reason to advertise > Job Manager's > >> > >>> > > > REST > >> > >>> > > > > > > > endpoint > >> > >>> > > > > > > > > > > > address in a form of IP address instead of > >> > >>> > hostname? More > >> > >>> > > > > > > > precisely, > >> > >>> > > > > > > > > > I'm > >> > >>> > > > > > > > > > > > talking about this code block > >> > >>> > > > > > > > > > > > > >> > >>> > > > > > > > > > > >> > >>> > > > > > > > < > >> > >>> > > > > > > > > >> > >>> > > > > > > >> > >>> > > > > > > >> > >>> > > > > >> > >>> > > > > >> > >>> > > https://github.com/apache/flink/blob/release-2.0.0/flink-runtime/src/main/java/org/apache/flink/runtime/rest/RestServerEndpoint.java#L298-L304 > >> > >>> > > > > > > > > > >> > >>> > > > > > > > > > > >> > >>> > > > > > > > < > >> > >>> > > > > > > > > >> > >>> > > > > > > >> > >>> > > > > > > >> > >>> > > > > >> > >>> > > > > >> > >>> > > https://github.com/apache/flink/blob/release-2.0.0/flink-runtime/src/main/java/org/apache/flink/runtime/rest/RestServerEndpoint.java#L298-L304 > >> > >>> > > > > > > > > > >> > >>> > > > > > > > > > in > >> > >>> > > > > > > > > > > > RestServerEndpoint.java: > >> > >>> > > > > > > > > > > > > >> > >>> > > > > > > > > > > > final InetSocketAddress bindAddress = > >> > >>> > (InetSocketAddress) > >> > >>> > > > > > > > > > > > serverChannel.localAddress(); > >> > >>> > > > > > > > > > > > final String advertisedAddress; > >> > >>> > > > > > > > > > > > if > (bindAddress.getAddress().isAnyLocalAddress()) { > >> > >>> > > > > > > > > > > > advertisedAddress = this.restAddress; > >> > >>> > > > > > > > > > > > } else { > >> > >>> > > > > > > > > > > > advertisedAddress = > >> > >>> > > > > > > > > > > > bindAddress.getAddress().getHostAddress(); > >> > >>> > > > > > > > > > > > } > >> > >>> > > > > > > > > > > > > >> > >>> > > > > > > > > > > > That is (as far as I understood), if > rest.bind-address > >> > >>> > > > is set > >> > >>> > > > > > > > to the > >> > >>> > > > > > > > > > > > 0.0.0.0 wildcard (which means binding to > all available > >> > >>> > > > > > > > interfaces), > >> > >>> > > > > > > > > > then > >> > >>> > > > > > > > > > > > the advertised address will be the value of > >> > >>> > rest.address. > >> > >>> > > > > > > > Otherwise, an > >> > >>> > > > > > > > > > > > address in a form of IP address of the > specified > >> > >>> > > > > > rest.bind-address > >> > >>> > > > > > > > > > will be > >> > >>> > > > > > > > > > > > used. > >> > >>> > > > > > > > > > > > What if I want to bind the REST endpoint > to some > >> > >>> > specific > >> > >>> > > > > > > > address (for > >> > >>> > > > > > > > > > > > security reasons), but at the same time > advertise it in > >> > >>> > > > the > >> > >>> > > > > > form > >> > >>> > > > > > > > of > >> > >>> > > > > > > > > > > > hostname? Assuming that all the name > resolution things > >> > >>> > > > work > >> > >>> > > > > > > > correctly. > >> > >>> > > > > > > > > > > > > >> > >>> > > > > > > > > > > > For me particularly, the problem this > creates is with > >> > >>> > > > SSL. The > >> > >>> > > > > > > > > > certificate > >> > >>> > > > > > > > > > > > I have for the Job Manager (REST > connectivity) is > >> > >>> > created > >> > >>> > > > > > with a > >> > >>> > > > > > > > > > hostname > >> > >>> > > > > > > > > > > > and not an IP address. I run Flink on YARN > and this way > >> > >>> > > > the > >> > >>> > > > > > > > default > >> > >>> > > > > > > > > > value > >> > >>> > > > > > > > > > > > for rest.bind-address is Node Manager's > hostname (thus, > >> > >>> > > > not > >> > >>> > > > > > the > >> > >>> > > > > > > > 0.0.0.0 > >> > >>> > > > > > > > > > > > wildcard), and the same goes for > rest.address. This > >> > >>> > > > way, the > >> > >>> > > > > > > > advertised > >> > >>> > > > > > > > > > > > address is in the form of an IP address. > I'd like to > >> > >>> > > > access > >> > >>> > > > > > > > Flink's UI > >> > >>> > > > > > > > > > via > >> > >>> > > > > > > > > > > > the YARN Resource Manager proxy ("Tracking > URL" in the > >> > >>> > > > > > application > >> > >>> > > > > > > > > > page) > >> > >>> > > > > > > > > > > > that has the Job Manager's certificate in > its > >> > >>> > truststore. > >> > >>> > > > > > > > However, due > >> > >>> > > > > > > > > > to > >> > >>> > > > > > > > > > > > the Flink being advertised to Resource > Manager with > >> > >>> > the IP > >> > >>> > > > > > > > address and > >> > >>> > > > > > > > > > the > >> > >>> > > > > > > > > > > > certificate holds the hostname, the > connection from > >> > >>> > > > Resource > >> > >>> > > > > > > > Manager > >> > >>> > > > > > > > > > to Job > >> > >>> > > > > > > > > > > > Manager fails with: > >> > >>> > > > > > > > > > > > > >> > >>> > > > > > > > > > > > javax.net.ssl.SSLPeerUnverifiedException: > >> > >>> > Certificate for > >> > >>> > > > > > > > > > <192.168.33.11> > >> > >>> > > > > > > > > > > > doesn't match any of the subject > alternative names: [] > >> > >>> > > > > > > > > > > > > >> > >>> > > > > > > > > > > > The only way I can fix this (without code > changes) > >> > >>> > is by > >> > >>> > > > > > > > explicitly > >> > >>> > > > > > > > > > > > setting rest.bind-address to 0.0.0.0, > which is not > >> > >>> > > > secure, as > >> > >>> > > > > > > > far as I > >> > >>> > > > > > > > > > > > understand (less secure than binding to a > specific > >> > >>> > > > address). > >> > >>> > > > > > > > > > > > However, if I substitute the > getHostAddress() call in > >> > >>> > > > the code > >> > >>> > > > > > > > block > >> > >>> > > > > > > > > > above > >> > >>> > > > > > > > > > > > with the getHostName(), the issue is gone. > >> > >>> > > > > > > > > > > > > >> > >>> > > > > > > > > > > > So, my question is: is there any > particular reason > >> > >>> > not to > >> > >>> > > > > > > > > > > > use getHostName() here (assuming hostname > is > >> > >>> > available)? > >> > >>> > > > > > > > > > > > > >> > >>> > > > > > > > > > > > Thanks, > >> > >>> > > > > > > > > > > > Yaroslav > >> > >>> > > > > > > > > > > > > >> > >>> > > > > > > > > > > > >> > >>> > > > > > > > > > > >> > >>> > > > > > > > > > >> > >>> > > > > > > > > >> > >>> > > > > > > > >> > >>> > > > > > > >> > >>> > > > > > >> > >>> > > > > >> > >>> > > > >> > >>> > >
