We have an application setting the protocols in urls based on cgi.https being on/off.
The value of cgi.https is set in Lucee 6 and also in Lucee 5.
The value of cgi.https is an empty string in ColdFusion 2021 (what our app uses) and it is also empty in ColdFusion 2016, 2018, and 2023. ColdFusion 2021 pictured below.
Is there another way to retrieve the value that should be in cgi.https in ColdFusion?
No load balancer is being used. This is a ColdFusion server spun up using CommandBox on a MacBook for local development.
Different servers use different things to specify the original protocol. I recommend checking all the things ColdBox checks here to account for all scenarios:
Now, as far as why ColdFusion or Lucee don’t show that specific CGI variable-- I have no idea what ColdFusion uses to back its CGI scope, but in Lucee, the following code is used:
return store(key, req.isSecure() ? "on" : "off"
where req is the HTTP Servlet Request.
And in CommandBox, the HTTP Servlet Request object comes from Undertow, which uses the following logic in its isSecure() method.
public boolean isSecure() {
return exchange.isSecure();
}
which delegates to the Server Exchange object in Undertow, which uses this logic:
public boolean isSecure() {
Boolean secure = getAttachment(SECURE_REQUEST);
if(secure != null && secure) {
return true;
}
String scheme = getRequestScheme();
if (scheme != null && scheme.equalsIgnoreCase(HTTPS)) {
return true;
}
return false;
}
The first if statement checks for if you used the
mark-secure()
predicate handler in your server rules to arbitrarily mark the request secure per some logic of your own making.
The second check looks at the actual scheme of the incoming request to see if it was “HTTPS”.
Now, that follows the path of what Lucee does. I would ASSUME Adobe also delegates to the servlet request, but who knows. They may have some custom logic going on that assumes their IIS web connector or something is in use. You’d have to ask them.
Also, this may be a dumb question-- but are you using SSL in CommandBox and are you actually hitting the HTTPS URL in your browser and confirmed it stayed there and didn’t redirect back to HTTP?
I’ll add (for Chris’ sake and Brad’s) first that I experience the same, in a request to a commandbox instance (running CF2023 or 2021 or Lucee, and in my case on windows FWIW). It seems (as Brad notes) to be about how the engines when running on Commandbox retrieve the state from the web server used (undertow).
But second, to Chris’s asking if any alternative may exist, this CFML variable will get you the value you want getpagecontext().getrequest().isSecure(), which for FR returns YES if the request protocol is https, or NO if it’s just http. With Lucee, it reports true or false, respectively. And to be clear I confirmed it works for both CF and Lucee whether running in Commandbox or not–and it always returns a value, never an empty string.
That may also serve as a clue or opportunity for Brad or anyone wanting to dig in further on how CF or Lucee don’t get any value for cgi.https when run within Commandbox.
Finally, FWIW, I compared all the other CGI vars (between a request run through CF, via commandbox or not), and this was the only CGI variable whose value changed between the two requests.
(Brad, if you may get notified by email or otherwise about these replies, please note that I have since tweaked a couple of sentences above–things which you may well have wanted to correct me on yourself. 
Just saying you may want to re-read my reply or look at the change history, as my tweaks might affect something you’d wanted to say.)
Just to confirm you experience
CGI.HTTPS in LuceeCGI.HTTPS in AdobeIt would appear this supports the idea that Adobe is not using the same HTTP Servlet Request isSecure() method that Lucee is using. I can’t imagine what other option they’d be using, but since ACF is closed source, it’s anyone’s guess. I’d say put in a ticket for them (Adobe).
I get the same as Chris: in Lucee the cgi.https reports off via commandbox, while CF reports empty string.
And yep, it would seem to be on Adobe to solve this (though technically one could say they should formally support Undertow as a web server, if formally supporting CF on Commandbox). They may at least tweak this one thing, if not going to the full extent of “formal support”.
In the meantime, though, the variable I offered will work for you, Chris (and anyone facing this).
Agreed, but they don’t really even need to support Undertow specifically per se. If they would simply follow the servlet specification like Lucee, this wouldn’t be an issue! The isSecure() method on the HTTPServletRequest object isn’t an Undertow standard, it’s just part of the servlet spec.
Well, yeah. My offer of the workaround shows that CF could use that, clearly, and it would work.
But I am assuming that the whole CGI variable framework in CF is something created 20+ years ago (and shoehorned to work with CF on Java starting in CF6), and they probably have been leverage web server-specific things since then…even though they COULD have changed to using more generic things where the servlet spec would have helped them.
So sure, one solution would be for them to change to using servlet-generic things (which would work with all web servers–and leave that work to the servlet spec, or for web server vendors to report to that).
But I suspect there are OTHER aspects of CGI variables where they maybe CAN’T just get their values from the servlet objects, and so they felt instead they HAD to go with web-server API calls. And THAT’s where I was proposing that they may feel they’d have to formally support undertow.
And to be clear, I think they SHOULD…since Commandbox has become a defacto standard way of running CF among a large percent of the dev population. Sadly, until they do that, all kinds of things will always be “a little different” when running CF within it. Heck, the most valuable thing would be if they would let WARs run on the CF Standard license–even if somehow ONLY when run via Commandbox. For any readers unaware, Commandbox runs by deploying CF or Lucee as a WAR–which is mostly transparent to you as a developer.
And where that notion of running CF in Commandbox as PROD may have seemed “an edge case” when commandbox was only used by most for development and from the command line, now with your Commandbox Pro/Service Manager module, those certainly engender using CF on commandbox for production–such that you may well BRING some users to wanting to run CF Standard on “new machines” (thus perhaps new CF licenses for them)–which could seemingly justify their putting in that effort.
But I suppose you’ve had enough such conversations with them over the years and may have grown weary of the fight. Again, I only bring it up in the context of at least getting them to formally support Undertow. But that, too, may be a battle you’ve given up fighting.
Chris, this broader support for undertow would be a point worth mentioning if you do file a bug report (at tracker.adobe.com) asking them about this cgi.https issue.
First off, thank you both for these detailed replies.
I tried both with and without SSL in CommandBox (dis/enabled in the server.json) and hit both the http and https URLs in the browser. Both returned an empty value for cgi.https (and other https related cgi vars also pictured in the original screen shot).
When I dump the cgi scope on our production server (Windows 2019 and ColdFusion 2021 Update 13) cgi.https and the other https related vars are populated.
Yep, that appears to be a bug in Adobe CF. Go yell at them in their ticket tracker
