CommandBox Docker Container rewrites issues

Hi,

I’m trying to use the CommandBox Docker container with a site I have running on CommandBox but the rewrites are not working. The app has the rewrites enabled in the server.json with the config pointing to the .htaccess file:

“rewrites”:{
“enable”:true,
“config”:".htaccess"
}

However, on startup I’m getting the following message output in the terminal:

web_1 | ****************************************************************
web_1 | INFO: Rewrite Flag detected, updating configuration…
web_1 | WARN: Existing rewrite configuration detected. Could not apply rewrites configuration.
web_1 | ****************************************************************

Once started the rewrites are not working. Any ideas?

Thanks.

Andrew,

This warn message is a little misleading (which I’m going to change for clarity). There seems to be a conditional that is firing incorrectly from this line https://github.com/Ortus-Solutions/docker-commandbox/blob/master/build/run.sh#L111, which looks for a URL_REWRITES flag in the environment.

The message, effectively, means that it has detected an explicit setting in the server.json file of the application and it is bypassing the default setting. From that point on CommandBox/RunWar handles the application of the rewrite rules, based on the configuration setting. I’ve just verified that it will correctly parse the .htaccess file with that setting enabled.

That said, .htaccess files are parsed by Tuckey, but only support a subset of mod_rewrite, with some caveats. For example, mod_rewrite conditionals that refer to Apache modules will not be parsed. See the bottom of this page, for information and caveats: http://tuckey.org/urlrewrite/manual/4.0/index.html

So, for example, this will work (and will throw a 404 for every request):

RewriteRule ^$ index.cfm [QSA,NS]

RewriteRule ^(.*)$ non-existentfile.cfm /%{REQUEST_URI} [QSA,L,NS]

But this will be ignored:

<FilesMatch “.(ttf|otf|eot|woff)$”>

Header set Access-Control-Allow-Origin “*”

I will change that error message for clarity, though. My apologies for any confusion.

Thanks,

Jon

Hi Jon,

I’m sure it is not the contents of the .htaccess file that is the problem as it worked with CommanBox normally for the same app, it is only when I’ve tried to launch the app with the Docker version that I’m getting the problem. I’m going to try and convert the rewrite rules the Tuckey XML format instead, they are relatively straightforward and see if that works instead.

Are you using the latest image? There was a regression in a previous version of CommandBox, if I remember correctly, with relative paths on that rewrite config file setting, when running in Docker. You might try “./.htaccess” as the setting and see if that picks it up.

Hi Jon,

Yes, on the latest as I’m using the “latest” tag in the Dockerfile.

The addition of the ./ appears to have done the trick.

Thanks.

Hi Andrew, just to confirm, are you saying that your rewrites don’t work because you specifically tested then and they’re not firing, or are you guessing that they don’t work just due to the warning message below (which, as Jon pointed out, is simply saying that you have a custom rewrite config so the Docker image isn’t’ going to try and add rewrites in itself).

If you’re rewrite aren’t working, you can get a metric crap ton of debugging by adding in a couple of flags.
https://ortus.gitbooks.io/commandbox-documentation/content/embedded_server/url_rewrites.html#logging

Trace gives you a bit extra info than debug from Tuckey. If you enable the little status page, make sure you’re rewrites don’t mess with it. You can just hit yoursite.com/tuckey-status when you follow the setting shown in the doc above and Tuckey generates a little HTML page that shows you all of the rules that have been loaded. The debug flag also give you blow-by-blow status as each rule is run and what the outcome of the rule is. It should be pretty easy to tell if the rules are firing or if they’re going off the rails somewhere in their logic.

Thanks!

~Brad

ColdBox/CommandBox Developer Advocate
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

Hi Brad,

No, it wasn’t just the warning message, it wasn’t actually working in the browser but adding the ./ to the file path for the .htaccess has solved it.

Is the .htaccess file in the same folder as the server.json? I just reviewed the code and I don’t understand why the ./ would be required unless this is some sort of bug in Unix that applies possibly to file that start with a dot.

When you specify a web.rewrites.config in your server.json, this code in CommandBox runs:

// relative rewrite config path in server.json is resolved relative to the server.json
serverJSON.web.rewrites.config = fileSystemUtil.resolvePath( serverJSON.web.rewrites.config, defaultServerConfigFileDirectory );

That should take a path that’s relative and make it absolute using the same folder that the server.json file is in as the base.

What do you get if you CD into the directory where your server.json file lives and run this code from inside the CommandBox REPL? (The dollar sign is part of the variable name)

$filesystemUtil.resolvePath( ‘.htaccess’ )

On Windows, I just did that from a folder called *D:\commandbox* and the output was (correctly) D:\commandbox.htaccess
I’d like to know if this is a bug on Unix though.

Thanks!

~Brad

ColdBox/CommandBox Developer Advocate
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

No sooner did I send this and I saw Jon also put in this ticket. See my comment on it for an additional bit of test code you can run from the REPL to help nail the behavior difference between WIndows and *nix down.

https://ortussolutions.atlassian.net/browse/COMMANDBOX-709

Thanks!

~Brad

ColdBox/CommandBox Developer Advocate
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com