So, traditionally I’ve always had a Coldfusion developer server setup locally using Apache .htaccess for rewrites. I’ve been slowly transitioning all my production sites to Lucee and in the next month or so they will all be converted. Decided the time was ripe to convert to Lucee locally (Mac) as well, and boy, that proved frikkin’ harder than I thought (…). I finally decided to give Commandbox (via Homebrew) a whirl and was done in like 5 minutes, so that was a welcome change. It’s looking like this is the way to go for me for sure.
But, I’m hitting an issue very specific to the following condition in my .htaccess file, which I’m loading with “box server start --rewritesEnable rewritesConfig=.htaccess --debug --console --follow”
I’m getting the following error: Condition 1 had error: you must set a name for a header
And that’s referring to the following: RewriteCond %{REQUEST_FILENAME} !-d
It’s also actually choking on that as it wants the {} to be escaped, but even if I do that, it kicks back the above. This doesn’t seem to be one of the exceptions noted here: UrlRewriteFilter - Manual
I noticed Brad with a comment here [COMMANDBOX-75] URL Rewrites - Welcome regarding using the same.
What am I missing here? While I could go rewriting everything, the main idea of switching locally was to have less differences with the production setup, not more.
I did some more testing and still can’t get this to work (posting here for future reference, as most of my manuals have been this type of post). Given part of the charm of Commandbox was the ‘it just works’ appeal, I’ve decided to go back to Lucee using .war which will mirror more closely what I have in production. I still can’t get .htaccess to work there, so going to have to scrap that whole way of working. I have no idea how/why this is so hard when it’s pretty straightforward in Coldfusion but I’m going to have to bite the bullet at some stage. The problem seems to have to do with apache passing off everything to tomcat, which obviously doesn’t read the .htaccess, but this does just work in Coldfusion, so that’s annoying. I’m guessing this is tied to the proxypass way of doing things, but that’s way beyond my understanding. Anyway, that’s probably a discussion better suited for the lucee group
Hi Sam, sorry you still have this issue. I think the problem can be with your ajp, yes!!! If you are using some sort of actual tomcat, there is a pretty new attribute set in Tomcats ajp connector with a shared secret because of the ghostcat vulnerability. That is a requirement!!! Did you take a look into it? Don’t know how to connect it with Apache in AJP, because I’ve used AJP only with Windows boxes. In my Linux VPS Apache2 everything is purely passed with reverse proxy to tomcat port 8888, no AJP in there. I’ll check my settings as soon as I have my notebook with me. I really think that might be a possibility. Still, I would stick with commandbox. If’ve set almost all my dev roots to run with commandbox. It works great and can run Adobe or Lucee and switch between versions. Look into this AJP secret share thing, or set your Apache configs to log in debug modus.
I’m going to give this a few more attempts, then test Commandbox again, but if I can’t get the htaccess to work there, I’m switching back to Coldfusion for testing locally. Major bummer, but can’t lose more days of work on this
Hi Sam, very weird all this stuff. But the dev post you've mentioned
could help. Here is what I would try first:
1. Set apaches2 logging in the httpd.config to "LogLevel debug" and
see what the error.log outputs first, maybe this can help you
tacle/isolate the problem.
2. Try ditching AJP first, and proxy reverse. You need to have
mod_proxy enabled, but you know that already. Here are the settings
apaches2 gets from the Lucee Linux installer (as you can see, it
hasn't AJP enabled).
Then you can run a commandbox server instance with a fixed port 8888.
It could be set not to be allowed.
3. Also look in your apache2 configuration if overriding with
.htaccess is allowed ( AllowOverride All) for the directory you are
having the .htaccess file.
The URLRewrite should always work in the front end webserver, not
commandbox and not Lucee/Tomcat. Setting it up in commandbox or
Lucee/Tomcat is when you have no webserver set up in front.
That all should be a quick try. After that I really don't know what
else to say. Wish you best luck!
Ok, I’ve now cleaned up all the tests/tomcat/lucee installs, reverted httpd.conf to a clean version and gone over completely to commandbox. I need to just figure out why the .htaccess file is choking on something as standard and basic as RewriteCond %{REQUEST_FILENAME} !-d. This seems to be the exact same issue that was troubleshot at Standard HTACCESS rules error · Issue #104 · cfmlprojects/runwar · GitHub a little over 2 years ago, so I’ve posted a reply there hoping one of the OP’s can chime in.
Visiting {localhost}/rewrite-status seems to indicate there is something wrong with rewritecond as a whole, since it shows:
"Given that the following condition is met.
server-name is NOT equal to the value [NC]"
For “RewriteCond %{HTTP_HOST} !^(127.0.0.1|www.|skylancing.local$) [NC]”
Seem to be narrowing down, but at the same time it seems strange to me I’m the only one hitting this (seemingly).
I’ve simplified things down to the bone, and it’s definitely RewriteCond things are falling apart on. If you just have this as the entire .htaccess file:
If you believe there is a bug, please enter a ticket. If you need a fix asap, you can purchase support from Ortus to look into this right away. Otherwise, I don’t really know when I’ll have a chance to check it out. The Tuckey project is open source, so feel free to debug the Java code to see if it’s a bug in the library.
I am not confident enough in my own knowledge here to say there is a bug I’m afraid. But I stripped my htaccess down to one condition with one rule, which basically is saying, if host is not “127.0.0.1” then redirect to secure version with www. in front.
In my debug trace I get this while building out the redirect file (note specifically “loaded condition server-name null [NC]”):
[DEBUG] utils.ModRewriteConfLoader: processing line: RewriteCond %{HTTP_HOST} !^(127.0.0.1) [NC]
[DEBUG] utils.ModRewriteConfLoader: about to parse condition
[DEBUG] utils.ModRewriteConfLoader: processing line: RewriteRule ^(.)$ https://www.%{HTTP_HOST}/$1 [R=301,L]
[DEBUG] utils.ModRewriteConfLoader: got rule ^(.)$ https://www.%{HTTP_HOST}/$1 [R=301,L]
[DEBUG] utils.ModRewriteConfLoader: parsed rule part ^(.*)$
[DEBUG] utils.ModRewriteConfLoader: parsed rule part https://www.%{HTTP_HOST}/$1
[DEBUG] utils.ModRewriteConfLoader: parsed rule part [R=301,L]
[DEBUG] urlrewrite.Conf: now initialising conf
[DEBUG] urlrewrite.Condition: loaded condition server-name null [NC]
[DEBUG] urlrewrite.RuleBase: loaded rule Rule 0 (^(.*)$, https://www.%{server-name}/$1 2)
[DEBUG] urlrewrite.NormalRule: loaded rule Rule 0 (^(.*)$, https://www.%{server-name}/$1 2)
[DEBUG] urlrewrite.Conf: conf status true
[DEBUG] urlrewrite.UrlRewriteFilter: inited with 1 rules
[DEBUG] urlrewrite.UrlRewriteFilter: conf is ok
[INFO ] urlrewrite.UrlRewriteFilter: loaded (conf ok)
And then calling that page:
[DEBUG] utils.ServerNameMatcher: looking for hostname match on current server name 127.0.0.1
[DEBUG] urlrewrite.UrlRewriteFilter: checking for status path on /testingcond.cfm
[DEBUG] urlrewrite.UrlRewriter: processing request for /testingcond.cfm
[DEBUG] urlrewrite.RuleBase: Rule 0 run called with /testingcond.cfm
[DEBUG] urlrewrite.RuleBase: matched "from"
[DEBUG] urlrewrite.Condition: evaluating “127.0.0.1” against [NC]
[TRACE] urlrewrite.Condition: outcome false
[DEBUG] urlrewrite.Condition: not equal operator in use
[DEBUG] urlrewrite.RuleBase: conditions match
[DEBUG] substitution.VariableReplacer: variable %{server-name} type: server-name
[DEBUG] substitution.VariableReplacer: resolved to: 127.0.0.1
[DEBUG] substitution.MatcherReplacer: found 1
[DEBUG] substitution.MatcherReplacer: replaced sb is //testingcond.cfm
[DEBUG] substitution.VariableReplacer: replaced sb is https://www.127.0.0.1//testingcond.cfm
[DEBUG] urlrewrite.RuleExecutionOutput: needs to be permanentely redirected to https://www.127.0.0.1//testingcond.cfm
So it is evaluating 127.0.0.1 against [NC] and not against the actual server name, due to some issue when reading the file and building the conf.
I don’t mind purchasing support for this, but based on the above, are we looking at an issue with commandbox and its handling of .htaccess, or is this a Tuckey issue? I saw you helped out someone some years ago here with the same issue ( https://github.com/cfmlprojects/runwar/issues/104 ), so either this is something that has existed for years (and I’m just the second person to hit it?) or there is some local setting buggering this all up.
Do a --trace start and you’ll get a lot more information out. What you posted is just a debug start.
CommandBox is the CLI tool written in CFML that starts your servers (whose code I control)
It bundles a library called Runwar written in Java that actual fires off the server process (whose code I now control as well)
Runwar bundles a fork of the library called Tuckey which is a J2EE servet filter-based rewrite engine (whose code is controlled by another developer)
In this next release, we’re switching to the upstream Tuckey project (also controlled by another dev). It is fairly stagnant and hasn’t received commits in a while, but we can fork it and fix bugs and use that forked version if needed.
There are not a lot of people who use the .htaccess support in Tuckey. Tuckey’s default rule file is an XML file format and I assume whatever you’re doing would probably work in the XML. I assume there may be an issue with the parsing of the .htaccess file and creation of rules.
I don’t mind purchasing support for this, but based on the above, are we looking at an issue with commandbox and its handling of .htaccess, or is this a Tuckey issue?
So the answer is both yes and no. The specific code is in the Tuckey library, but it’s part of the graph of dependencies that CommandBox includes to do it’s thing. And at the end of the day, Ortus has the ability to find and fix any bugs in Tuckey if needed.
I saw you helped out someone some years ago here with the same issue
That’s Gavin, another Ortus employee. I don’t know if he ever went back and re-tested it to be honest.
Sam, I had a chance to sit down and take a poke at this today and this is what I found.
RewriteCond %{REQUEST_FILENAME} !-d works fine in my tests so I’m not sure what you were saying didn’t work there. You never provided an actual repro case for the issue you said you were having.
RewriteCond %{HTTP_HOST} !^(127.0.0.1) [NC] does NOT work due to a bug in Tuckey. More specifically, flags aren’t supported at the end of rewritecond statements. In that example, the no case flag is worthless since you are comparing an IP address so you could just remove the [NC] and it would work fine. FWIW, your regex is also invalid since you should be escaping the periods in the IP in the regex, but that’s another matter.
We’re going to manually merge that fix into our fork of the Tuckey rewritefilter project and see if it works. If so, this will be fixed in an upcoming release (not sure when yet)
As far as the first bullet point, you’re going to need to be more specific on exactly what you tried and how it didn’t work because our tests worked fine.
Sorry for the tardiness in replying - I decided after your last reply to take a step back and a day off. Then I approached it fresh with a view of what I was really trying to accomplish here. I realized it was 1) switch to lucee and 2) mirror production as best as possible. Hence the .htaccess to begin with. This was important as I started going down rabbit holes just trying to get a working solution (rewrite.configs/xml solutions etc). I decided something must be wrong with my setup elsewhere. Possibly due to the upgrade to Apache 2.4, or the Tomcat upgrade to 9. I uninstalled both, and everything else that could possibly be interfering and started totally fresh with the .war solution that Lucee seems to recommend for mac users.
I finally got it all working as is. I did run into snags along the way, and I am now wondering if fixing those also resolved this, so in the interest of all I am going to spin up a commandbox server soon and see if that too now works. It almost has to have been something locally as I can’t understand why it was wanting me to escape the {} to begin with. I’ll keep you posted on how that goes.
So apologies for bringing this up, though it’s good to see at least parts of what I mentioned weren’t just down to my setup. It’s also interesting to see that Gavin hit the exact same error a few years ago. I ended up using waybackmachine on his blog as one of the more helpful sources of info for mac users setting up lucee with htaccess.
WRT that one rule - that was just me stripping back everything and ending up with that to see how simplified I could get the htaccess to still trigger an error. Should have tried stripping the [NC] as well!
