mod_xyzand is really more of a standard implemented by several different libraries. The way ModCFML works, is the front-end web server (IIS, Apache, Nginx, etc) passes a few custom HTTP headers to the back end CF server on each request that tells the CF server where the web root lives for that site. Here's an overview of the related libraries:
ModCFML.enableis set to
truefor the server.
falseFOR DEVELOPMENT PURPOSES ONLY to not require the shared key header to be present. This may simplify your local setup, but do NOT enable this on any externally-accessible web server as a malicious client could send their own HTTP headers and serve content from anywhere on your server's hard drive! Default is
timeBetweenContexts**** since Undertow is VERY fast to add new contexts.
scanClassPaths**** because it re-uses the existing class loader and cloned Undertow deployment from the default context so no jars at all need to be scanned.
loggingEnabled. There is already logging as part of Runwar and the
--debugflag when you start your server will automatically log additional bits.
responseCode**** because it is capable of adding the new context entirely on the fly and using it immediately without needing to re-send the request.
X-ModCFML-SharedKey- Needs to match the
X-Tomcat-DocRoot- Needs to contain the absolute path to the web root for the current virtual host
X-Webserver-Context- Optional. Will be used instead of hostname to group multiple hostnames into a single context
X-VDirs- A string representing the aliases (virtual directories) of the web server for CommandBox to auto-create in the servlet in the format:
X-VDirs-SharedKey- Must also contain the same value as
X-VDirswill be ignored. This is for security since the older mod_cfml Apache proxies don't override a missing
X-VDirheader, allowing malicious client to pass one. Only pass the
X-VDirs-SharedKeyheader if your proxy is explicitly controlling the contents of the
tracelevel messages that will appear in the console when you start your server with the
--traceflag that will tell you when a new context is deployed and what the web root is.
/and will share the same class loader as the default instance, so they will also share the same server context. Adobe only uses the default servlet context, but swaps out the resource manager per-request, just like Adobe's Tomcat-based installations work. If you don't know what all that means, don't worry.
server.jsonfor a simple setup. Note, we're using the
commandbox-hostupdatermodule here to auto-create
hostsfile mappings for our domains. We're also pointing the webroots to
site3.comfolders inside of the default web root, but these could really point anywhere you like.