Hi, I’m trying to debug some application errors, but the cgi.http_referer is always listed as a http-nio-8888-exec-x (x= a number) I am not able to see the actual referring page.
Anything I can do to get the actual referrer?
Don’t forget to tell us about your stack!
OS: Alma Linux 9
Java Version: 21.0.6
Tomcat Version: r Apache Tomcat/10.1.39
Lucee Version: 6.2.0.321
Well, what you see there is a thread name, and it looks to be the thread of the http request you’re running–which should not be what’s in that variable, of course.
Let’s have you see what’s in the incoming headers:
WriteOutput(cgi.http_referer) Writedump(gethttprequestdata().headers.referer) WriteOutput(server.lucee.version)And to be clear, what you see is not what is reported if one runs this code at trycf.com, whose Lucee 6 version is still 6.2.1.122:
Are you using a Webserver in front of Lucee?
If so does this happen when you access tomcat directly on port 8888
I am running with Apache , I can’t access pages on my domain with port 8888.
Port 8888 on the IP shows me the welcome to your lucee 6 installation
Here’s what I get when I put
<cfscript>
WriteOutput(cgi.http_referer)
Writedump(gethttprequestdata().headers.referer)
WriteOutput(server.lucee.version)
</cfscript>
"The key [referer] does not exist. Available keys are [accept, accept-encoding, accept-language, cdn-loop, cf-connecting-ip, cf-ipcountry, cf-ray, cf-visitor, connection, cookie, host, priority, sec-ch-ua, sec-ch-ua-arch, sec-ch-ua-bitness, sec-ch-ua-full-version, sec-ch-ua-full-version-list, sec-ch-ua-mobile, sec-ch-ua-model, sec-ch-ua-platform, sec-ch-ua-platform-version, sec-fetch-dest, sec-fetch-mode, sec-fetch-site, sec-fetch-user, upgrade-insecure-requests, user-agent, x-forwarded-for, x-forwarded-host, x-forwarded-proto, x-forwarded-server, x-modcfml-sharedkey, x-tomcat-docroot, x-webserver-context].;The key [referer] does not exist. Available keys are [accept, accept-encoding, accept-language, cdn-loop, cf-connecting-ip, cf-ipcountry, cf-ray, cf-visitor, connection, cookie, host, priority, sec-ch-ua, sec-ch-ua-arch, sec-ch-ua-bitness, sec-ch-ua-full-version, sec-ch-ua-full-version-list, sec-ch-ua-mobile, sec-ch-ua-model, sec-ch-ua-platform, sec-ch-ua-platform-version, sec-fetch-dest, sec-fetch-mode, sec-fetch-site, sec-fetch-user, upgrade-insecure-requests, user-agent, x-forwarded-for, x-forwarded-host, x-forwarded-proto, x-forwarded-server, x-modcfml-sharedkey, x-tomcat-docroot, x-webserver-context]. Only the following keys are available [ accept, accept-encoding, accept-language, cdn-loop, cf-connecting-ip, cf-ipcountry, cf-ray, cf-visitor, connection, cookie, host, priority, sec-ch-ua, sec-ch-ua-arch, sec-ch-ua-bitness, sec-ch-ua-full-version, sec-ch-ua-full-version-list, sec-ch-ua-mobile, sec-ch-ua-model, sec-ch-ua-platform, sec-ch-ua-platform-version, sec-fetch-dest, sec-fetch-mode, sec-fetch-site, sec-fetch-user, upgrade-insecure-requests, user-agent, x-forwarded-for, x-forwarded-host, x-forwarded-proto, x-forwarded-server, x-modcfml-sharedkey, x-tomcat-docroot, x-webserver-context ].;lucee.runtime.exp.ExpressionException: The key [referer] does not exist. Available keys are [accept, accept-encoding, accept-language, cdn-loop, cf-connecting-ip, cf-ipcountry, cf-ray, cf-visitor, connection, cookie, host, priority, sec-ch-ua, sec-ch-ua-arch, sec-ch-ua-bitness, sec-ch-ua-full-version, sec-ch-ua-full-version-list, sec-ch-ua-mobile, sec-ch-ua-model, sec-ch-ua-platform, sec-ch-ua-platform-version, sec-fetch-dest, sec-fetch-mode, sec-fetch-site, sec-fetch-user, upgrade-insecure-requests, user-agent, x-forwarded-for, x-forwarded-host, x-forwarded-proto, x-forwarded-server, x-modcfml-sharedkey, x-tomcat-docroot, x-webserver-context].
Ok, so that confirms the request HAS no referer header. (Notice how the error lists which headers DO exist in that request.)
And the way the cgi scope should work is that if a requested key doesn’t exist, it should return an empty string. (And yes, Lucee maintains cf’s longstanding behavior of having the referer header exposed instead as the http_referer key in the cgi scope.)
So there’s definitely something odd, that Lucee’s returning a thread name for the key/variable, when the header simply doesn’t exist. You’ll want to file a bug, it seems. (More in a moment.)
As a workaround, you could use the Elvis operator to return empty string when it doesn’t exist:
gethttprequestdata().headers.referer ?: “”
It’s clunky, but you could also put it in a function:
function gethttp_referer () {
return gethttprequestdata().headers.referer ?: “”
}
And then change your references to the variable to call that as in:
WriteOutput(gethttp_referer() )
Finally, as for reporting it, you’ve now also clarified to Zac that you’re using apache. I’d next ask if you’re using a forward send requests to Lucee’s port 8888? If so, perhaps that’s another clue for the engineers.
(We can’t know how trycf.com is configured. Also, the fact that it had its domain name in the referer is likely just a quirk of some internals of how that site protects itself with redirects, etc.)
It would of course help if you could easily confirm/deny the problem on 6.2.1.122, or the latest snapshot, but I appreciate that doing such testing is easier for some than others.
As always, just trying to help.
Let’s ignore that exception for now, CGI scope will return empty strings for missing keys.
I see cloudflare headers in that list, let’s remove all the complexity and focus on reproducing this on localhost without Apache or cloudflare?
does either x-forwarded-host or x-forwarded-server contain the value you’re looking for?
Thanks yes that now shows whatever it can find - most appear to be from Bots
Thanks for your help
Nick, what’s your conclusion here? It seems you’re satisfied, but I’d argue that there’s still something wrong if cgi.http_referer ever returns a thread id (as you originally found).
And are you saying now that the behavior may change based on what you find in those forward headers? That would seem worth including in a bug report, as cgi.http_referer should only EVER hold the referer header–which should only ever be a url, if anything.
As you may know, it’s typically populated by a browser, when a user clicks a link: so for instance, while viewing page a and clicking a link to page b, the cgi.http_referer on b would show the url for a. If someone just visits page b directly, such as typing the url in the browser address bar, there would be no referer and so cgi.http_referer would be the empty string.
Similarly, the cgi.http_refererrr should be empty for most bots, as they tend to request the page directly without sending the referer header.
Just curious whether and how you’re perhaps concluding this thread. Not badgering: just trying to help you–and others following along. 