proxyName / proxyPort Connector properties

[gvdev-git]

The server does not seem to respect the proxyName / ProxyPort Tomcat connector properties, i.e. it does not use request.getServerName and request.getServerPort, but seems to return links within the JSON response built on the request header. This effectively prevents deployment of the server behind a reverse proxy.
Example response:

links |
    0 |  
        value | "http://127.0.0.1:8080/domain/mydomain.tld."
        rel | "self"
        href | "http://127.0.0.1:8080/domain/mydomain.tld."
        type | "application/rdap+json"

Offtopic: I assume that the X-Forwarded-For HTTP header is ignored as well. This may create problems later on when IP authentication becomes relevant

[dhfelix]

I thought we already had that case covered. I'm going to check what could have happened.

[dhfelix]

After some research, the reason that I though was fine, it is because in my apache's test conf for the reverse proxy site, I added the value ProxyPreserveHost on

<VirtualHost *:80>
...
 ProxyPreserveHost on
 ProxyPass / http://localhost:8080
 ProxyPassReverse / http://localhost:8080
...
</VirtualHost>

and in my test conf for nginx, I added proxy_set_header Host $http_host;

server {
    listen 80;
    location / {
        proxy_pass http://localhost:8080;
        proxy_set_header Host $http_host;
    }
}

Offtopic: I assume that the X-Forwarded-For HTTP header is ignored as well. This may create problems later on when IP authentication becomes relevant

As far as I know, in the Rdap-server we don't drop headers.

I need to search which are the best practices for this kind of issue with headers, (I assume you followed this guide https://tomcat.apache.org/tomcat-8.5-doc/proxy-howto.html but what happen when other fellow wants to use another application server for RedDog-server)

[gvdev-git]

That's a workaround which fixes the hostname in the JSON response. It does not fix the protocol though, i.e. it's still href | "http://rdap.myserver.tld/domain/mydomain.tld." instead of https. Of course you could reverse-proxy to https, but IMO that adds the unneccesary overhead of having a certificate in Tomcat as well.
Anyway thanks for the pointer!