Request server (hostname:80) doesn't match forwarded server (hostname:null)

Discussion created by nick_darlington Champion on Jun 23, 2015
Latest reply on Aug 26, 2015 by MFJohnston

We've had a couple of reports of the following appearing in app-ca.log files since Clarity 14.x:

WARN  2015-06-22 17:23:41,577 [http-bio-80-exec-1122] web.WebControlServlet (clarity:admin:5357059__18A23EDF-51E7-4EA8-ACF7-613F8697FDD5:security.loginAction) Request server (hostname:80) doesn't match forwarded server (hostname:null)


So I would like to share some information on this.


On the one hand, the message is fairly benign; it can appear a lot (every hit/access even), and appear to spam the logs, but much of Clarity's functionality is unhindered by this message.


The specific complaint when the port number of the forwarded server is null like the example above, is that some part of the network infrastructure is adding an X-Forwarded-Host header in the http packets sent to Clarity from users, and not also adding an X-Forwarded-Port header with it (to match the port that your Clarity app service is listening on).


If the port numbers are different in the message and the latter one is not null, or the hostnames are different, that may be an indication of some cross site scripting (XSS) issue or even attack and your network teams should be engaged to investigate another concern altogether.  However if the latter port number is null as above and all else remains the same, then it is just the fact that just the X-Forwarded-Host was sent and not the other one with it.


To remedy this, either locate the network hardware (a proxy server or load balancer is likely) that is adding X-Forwarded-Host to the messages, and then configure it to also include X-Forwarded-Port with the correct values, or configure it to remove X-Forwarded-Host.  This will then avoid the confusion taking place and log spam.


There may be some pages in Clarity where the presence of this message may cause more issues than simply some log spam, but we don't have proof of that yet and are still researching claims to determine if the faults occurring are also due to this or have some other cause behind them.  I will reply with more information as we learn about any other symptoms, but the solution will still be the same (add the port header or remove the host one).