Migration to cgi.server_name and server_port did not account for the incoming browser port but the cf service port


Migration to cgi.server_name and server_port did not account for the incoming browser port but the cf service port.

This causes issues where the browser port is diff than the cf service port. Get the port from the cgi.http_host instead.


Joseph Gooch
November 13, 2020, 3:12 PM

Using CommandBox, basic tests:

Lucee 5.3 - CGI.Server_Port FOLLOWS HTTP_HOST - if no port is in HTTP_HOST, it’ll default to 80 or 443 (no idea if it actually follows the isSecure in the underlying Request object)

ACF 2016 - CGI.Server_Port ALWAYS equals the Listening Port of the server, REGARDLESS of HTTP_HOST


FullURL is just broken in all cases with a non-root app


I’ve always used CGI.HTTP_HOST because that’s coming directly from the browser. Anything else is a dilution of that information. (SERVER_NAME and SERVER_PORT being set USING HTTP_HOST, or defaulting to local server information if not set). The fact that diff servers do it differently, and likely are influenced by tomcat’s RemoteIPValve makes me feel more strongly that you should be parsing HTTP_HOST directly instead of relying on server specific behavior.

And providing all the options for increased choice and centralizing the logic

Joseph Gooch
November 13, 2020, 1:52 PM

What I want:

  1. I want our html base tag to be absolute, WITHOUT proto and port. /cbox-groovyloader/ or /farcry/ or whatever.

  2. I want ALL our application links to be absolute, WITHOUT proto and port. /cbox-groovyloader/index.cfm/groovy or whatever

  3. I want the ABILITY to get the full URL for an event.
    Examples - Java Webstart JNLP files, passing a url to Electron apps, Providing a full URL in emails


  1. Why are various templates guessing the hostname? IMHO, you should not be referencing CGI scope throughout the app.

  2. In my app, I have Request.sslserverurl, Request.nonsslserverurl, Request.AppRoot.
    These are set in onRequestStart.
    It handles all the logic for handling X-Forwarded-For, X-Forwarded-Proto, X-Front-End-Https, etc
    It uses HTTP_HOST and SERVER_NAME or SERVER_PORT to figure all these things out, once

  3. Maybe you need a RequestURLService? Why is the Router doing one calculation and theen RoutingService does another?

  4. Why is the hostname IMPORTANT in these values? What caching is happening by hostname?

Relevant information
Under Variables section in Tomcat's SSI document
SERVER_NAME The server's hostname or IP address.
HTTP_HOST The web site that the client requested.
Using HTTP_HOST variable in RewriteRules fixed my problem.

Based on the above, the definition and behavior of HTTP_HOST is exactly what you should be using.
I'm not sure what problems you had with event caching. I'm not sure how you reproduce them. I've never seen HTTP_HOST be anything other than exactly what the browser is sending through. A proxy in the middle could muck around with it.

  1. Ultimately these are the facts.
    1) In absense of a Host: header, there's literally no way for the server TO KNOW what host the browser is using to reference the site. In that case I expect SERVER_NAME to be the host name of the linux instance CF is running on, which in my case will ALWAYS be wrong. A web request to myloadbalancer.domain.com will be handled with MyBackend1.domain.com:8181 (or one of tons of other instances).
    2) If HTTP_HOST is supplied, then it appears SERVER_NAME IS HTTP_HOST minus the port, which means it's no more or less "secure" than other options. I believe the security argument I referenced was in Nginx rewrite rules - something about using http_host instead of a host variable that did mapping.
    Specifically using $host vs $http_host

I've shown what I want above. I'm also aware that others might want something different.



Luis Majano


Joseph Gooch



Fix versions