Apache/mod_cfml question. I know I can control th...
# lucee
b
Apache/mod_cfml question. I know I can control the extension which mod_cfml kicks in via the
CFMLHandlers
variable.
Copy code
CFMLHandlers ".cfm .cfc .cfml"
However, I'm testing with a setup in which I want ALL TRAFFIC to be proxied to a completely separate server where the actual application files live. This means CFMs AND static files will all be proxied and I need the magic of mod_cfml to fire on every request so the Lucee server knows the correct web root to use for each request. I can't find a way to pass a wildcard to the
CFMLHandlers
setting. I've tried passing
"*"
,
".*"
, and even just removing that setting, but mod_cfml will not seem to allow me to trick it into always firing. Any ideas? cc/ @utdream
z
having looked at the code, you need to request a .cfm first before it kicks in
b
That is not true.
You're thinking of a site that only proxies cfm files.
The first request of any kind bearing a new
X-Tomcat-DocRoot
request attribute will kick off the creation of the new context.
haven't looked at this in ages
b
For example, if I add
.txt
as a default handler, then I can hit that URL and it creates the context just fine.
But I don't want to add every file extension in existence, which also won't work for files not bearing an extension
Your ticket also appears to be specific to the Tomcat Valve's behavior. I'm using CommandBox's native ModCFML support which has no such issue šŸ˜‰
FWIW, here's my workaround for now • stop using mod_cfml • just set the http headers myself on every request Not really ideal, but ended up being about 10 times faster than getting mod_cfml to compile and install in a Docker container, lol
Copy code
RequestHeader set X-ModCFML-SharedKey modcfmlsecret
RequestHeader set X-Tomcat-DocRoot C:\Users\Brad\Documents\GitHub\commandbox-tests\modCFML\site1\
a
I also thought having seen some cfml file extension filter in mod_cfml code intercepting cfml template requests. The same problem applies to REST requests. Devs who use plain REST requests, don't get any web context automagically created by mod_cfml.
b
Seems like mod_cfml needs to re-think the options provided to us for what requests to proxy.
And even though my workaround "fixes" this, it also sort of defeated my purpose of _specifically testing if CommandBox's integration with mod_cfml worked_ šŸ˜†
šŸ‘ 1
a
Wait... Does that mean we can totall get rid of mod_cfml by just adding that header? Does that apply also to AJP?
b
yes of course-- that's always how mod CFML works šŸ™‚
All it does is add HTTP headers for you!
Everyone using it on NGinx just manually adds the headers themselves
That's essentially all Boncode does as well
The ModCFML Tomcat Valve and CommandBox's native modcfml implementation simply look for those headers to create the contexts.
Does that apply also to AJP?
It actually has nothing to do with AJP per se. CommandBox's modcfml will work for requests coming in over any listener type (AJP, HTTP, SSL)
šŸ‘ 1
This is why the modcfmlsecret is so important
Otherwise, any hacker out there can send an HTTP request to your tomcat server with an
X-Tomcat-DocRoot
header of
C:/windows/system
and Tomcat would happily create a context that served files up from the windows system folder!
So the Apache
mod_cfml
module basically ONLY includes the special headers for .cfm requests, meaning when I configure Apache to proxy ALL requests, even for static files, the request for a txt or jpg come across without the x-tocmat-docroot header and Tomcat/CommandBox just try to use the default context, which is no good.
When mod_cfml was designed, they assumed people would only always ever run apache and the servlet on the same machine, sharing the same hard drive!
This assumption falls apart as soon as you put the proxy on a totally separate machine and want it to proxy all traffic, including static files, to the backend server.
a
Super interesting
šŸ‘šŸ¼ 1
g
I Love learning these "internals"...