Cannot upload html files

No, I am not using application.cfc
In the admin, the listener is set to mix mode
Thanks for helping,

@Paul, For this issue. if you using with Application.cfc means, you can run without error. :slightly_smiling_face:

Please do not waste the time of people on this site.
I still hope somebody can help on this.

Sorry about your frustration, I’m back at my desk and I have a solution for you.

the default locked down config for Lucee uploads is


as per

in the constructor for your Application.cfc add in the following line


I have a filed a PR to improve the exception message

1 Like

Thanks Zac, however I have no idea where to find my "constructor for your Application.cfc "
I added the line in the Application.cfc, restarted Lucee and still have the same error. So I guess I need to know where "constructor for your Application.cfc " is.
Best regards,

the constructor is just the section at the start of your Application.cfc before any functions

component {
    // this is the constructor section = "myCoolApp";

    function onApplicationStart() {
        // do thing here if you need/want to

Thanks again Zak.
Unfortunately, I converted a ColdFusion application of a million + lines of code which was written at the time ColdFusion was Allaire and Application.cfc did not exist. My application uses many application.cfm and it would be a nightmare to convert to .cfc with absolutely no advantage (the application runs just fine as it is with Application.cfm, if not broken don’t fix it!).
Is there any possibility to fix the problem without using application.cfc?
Adding some code at the beginning of my Application.cfm’s ?
All my best to you,

Honestly, I haven’t even thought about application.cfm’s in a very, very long time

but converting them over to application.cfc really shouldn’t be that hard?

Thanks again Zac. Your solution works however I have some remarks on applicability and Application.cfm versus application.cfc.
You seem to believe that it “shouldn’t be that hard” to go from .cfm to .cfc. Well, it took me 3 weeks for one application. I had always suspected that this .cfc thing based on the general idea of object oriented was a mistake. And, yes, big mistake trying to convert application.cfm to application.cfc.
To my disbelief, I discovered that application.cfc runs ONLY ONE aplication and needs to be duplicated with its environment if you have multiple aplications running on the same system.

In my case, I had 15 different web sites all running the same code, all running under a SINGLE Application.cfm. When I converted to Application.cfc I discovered that every-time one of the web site was accessed it killed the (only!) other one running. Unless I am profoundly mistaken (correct me if so), the only solution I found was to duplicate 15 times Application.cfc and its environment to finally have a working system. Talk about progress: a single few pages of code now needing to be duplicated 15 times, with the nightmarish maintenance associated. 10 pages of code going to 150 pages of code. What a great progress!
This brings me to a point which maybe would deserve another blog entry : the original Allaire ColdFusion was developed to have a concise and very rapid development system using a high level language. Knowing only Java, the Adobe developers quickly made it a stupid copy of Java. Then ColdFusion has really no more reasons to exists. Why use ColdFusion when it became almost identical to Java?
A single page of code using the “old” style Coldfusion usually corresponds in 3 to 4 pages of the “object oriented” ColdFusion. This is not progress: it is going backwards.
If I was part of Lucee, I would go back to the basics and develop Lucee as ColdFusion was originally intended to be: a higher level language (much higher than Java, but I am not sure the Adobe engineers even understand that notion), easy and fast to develop. Get rid of this cfc crap! Be the real next generation language builders!
The goal of commercial computer languages is to allow an easier access to computers, an easier and faster programming, debugging and maintenance than using assembler code. It is not and SHOULD NOT BE to develop something based on a beautiful ideology on paper. There are languages like Lisp to do that, they are very interesting for university teaching, not for real world applications.
All of this being said, I want to thank all the Lucee team for the incredible work they do.

Hi Paul, thanks for posting your experience and thoughts. I’m chiming in because I would really like to know what experiences you had in more details. I know it’s possible to run different sites with one and only code base, but it all depends on how you want to run your applications and how you are setting it up. What was the problem in detail? Did your apps get in conflict because all contexts were being served by one WEB-INF folder? I think one possible solution could be pulling the WEB-INF folders out of the webroot. Did you try that?

what do you mean killed?

did you use a custom / dynamic application name per website?

Andreas, Zac:
Very schematically this is how one of my systems worked (and still works with Application.cfm).
Let’s suppose we have two web sites and Both use the same ColdFusion code but are very different.
Index.cfm (or any page) implicitly calls Application.cfm (a single one).

  • Application.cfm looks at CGI.SCRIPT_NAME to find which one of the two sites called.
  • Application.cfm queries a database common to all web sites and find the Application name associated with the caller. Ex: it find Application name = App1 for and sets AppName = “App1”
  • Application.cfm executes a <CFAPPLICATION Name="#AppName#" . . .
  • A single check on the existence of one Application variables (ex Application.Language) tells Application.cfm if this application just started or not.
  • If the application just started (Application.Language was undefined) Appliocation.cfm runs a query on a database for this App1 application. The database contains pairs of (name,values) for all Application variables we want to set for App1. A simple loop then sets the 150 to 200 specific Applications variables we want for App1

That has worked like a charm since ColdFusion Allaire
That does not work with Application.cfc as let’s suppose a call was made by It starts (Wonderful, I thought my Application.cfm was working!) BUT BUT
As soon as calls the stupid Application.cfc triggers on Application start , creates a new application with the name App2 and the environment of App1 which was running for is gone! Now App2 runs but App1 is dead and as soon as calls a page it restarts App1 (losing all the session and other App1 environment which was running before) and . . .kills App2!
I believe the problem is due to the fact that this stupid object structure makes Application.cfc part of the application it created when Application.cfm was “outside” the context of any application.

The only solution I found (after a few days of thinking, but maybe there is a better solution? Don’t hesitate to call me dumb if I missed something obvious) was to create a new “environment” folder for each application,, . . . and to duplicate Application.cfc and a few other necessary templates into each of those folders. For this to work, I created links into wwwroot to the folders for web1, web2, web3 . . .
This works but is very ugly and makes debugging and maintenance a nightmare.
Waht did I gain with Application.cfc? Nothing, Zilch, Niente, Rien du tout
O Yeah, the line OnApplication start did not exist and had to be replaced by a simple <CFIF IsDefined(" Big deal! What an advantage for .cfc!
What did I lose: a lot, un sacco, beaucoup, mucho mucho

Thanks again to both of you for your precious help.

Did you try setting based off cgi.http_host?


this is not the problem: the application name is set correctly. the problem is that as soon as an application name is set by application.cfc any other application which existed before is gone. the only solution l found was to duplicate application.cfc in different directories. you can try it yourself with a very simple setting (l did to try to figure out what was going on).

takes 10 minutes to try:

write a simplistic application.cfc. make it read a name on startup (from a file or whatever) do the cfapplication with this name. just to try, set a single application variable to whatever.

change the name in the file and browse to the code in a different tab or browser. application.cfc is executed and INSTEAD of creating a new application independent of the first one still running, it creates a new application environment destroying the first one. try to run the first browser the first app is gone.

Get BlueMail for Android

Adding to my answer above:
After checking that Application.cfc does not run two different applications, simply change Application.cfc to Application.cfm.
Now you can run the two apps at the same time, browsing from two different places.

can you provide us with this simple reproducible test case?

Hi Paul, as Zac said, did you try creating a dynamic application name on behalf of your host names? Something like below? And that didn’t work? Really would like to know a test case for this, because I think it shouldn’t be a problem.

<cfcomponent displayname="Application" output="false" hint="Handle the applications">

	<cfif cgi.http_host is "" 
	    	<cfset local.appID="web1" />
    <cfif cgi.http_host is "" 
	    	<cfset local.appID="web2" />
     <!--- Then set some application vars --->
    <cfset"appCF#local.appID#" />
    <cfset this.sessionTimeout=CreateTimeSpan(0, 0, 30, 0) />
	<cfset this.sessionManagement="yes" />
	<cfset this.setclientcookies="false" />
	<cfset this.sessionType="cfml"> 
    <cffunction name="OnApplicationStart" ...

Paul, as you’ve said… this isn’t a good solution at all. I’m sure someone will get this working somehow! Please post a simple test case so we can figure something out.

To test my problem, create an Application.cfc like:

Then create a template Test.cfm like:

Applicationname = #Application.Applicationname#
Application.test = #Application.test#

Browse to test.cfm. It correctly output the app name and test1
Now, change application.cfc to replace application1 by application2 and test1 to test2.
Browse again to test.cfm using a different tab or browser. It correctly output applcation2 as name and test2.
Go back to the first browser which was running Application1 and refresh
Surprise! it is now Application2 and all the context of application1 is gone.
Do the same with Application.cfm: all work as it should. Application1 is not destroyed as it should not be. only a time out or call to delete it should destroy it.

Sorry, I did not get a notification for your answer an completely missed it.
I will try your solution, however even if it works it does not solve the problem I have with Application.cfc.
As I tried to describe it, I believe Application.cfc is a HUGE step backwards and your answer confirms my feelings, even if it works. In fact it confirms my feelings even more if your solution works!
Having to dig into the Java structure with something like you propose (…cfset local.appID=“web1” /> . . .) demonstrates my point: something which worked effortlessly with Application.cfm now needs you to dig into undocumented Java stuff to try to make your code work!!! What a progress!!!
This is obviously a big step backwards and destroys the original idea of ColdFusion being a higher level language. What’s the point to use ColdFusion if you need to dig into Java to make your application run? Why not then simply code everything in Java? (or in assembly language ah ah ah)
I STRONGLY believe that if you want to succeed with Lucee and have a good impact on the market in the future your best route is to remember the basic ideas of ColdFusion and forget the stupid “improvements” of Adobe making ColdFusion a sub Java language instead of being a higher level.
Whatever a solution might be, Application.cfm works and Application.cfc does not. The rest is noise.
Please do not take this as a negative comment against you: I appreciate beyond limits what you do. I am simply trying to add a little grain of salt in what you do, hoping to help you myself in your venture.
Thank you so much for taking the time to read me and helping.

Hi Paul, I can understand you very, very well. I know your feelings, because I’ve been exactly there at some time in the past. And I don’t take your posts as a negative comment, not at all. To be sincere, I think of myself back in the classic cfml programming days, and to be honest it wasn’t a long time ago. There are things I still LOOOOOVE to use, like the good old cf tags like cfquery. But sometimes when dealing with different problems we need different solutions, and components and all this oop concepts addresses some of these important issues. I can only recommend trying it and learn a little about it, and as soon as you feel more familiar with it, you’ll notice it is a great thing to know and then you can always decide what is best for your specific situation/solution.

Comming to your test case, I’m really asking myself how could it work with the classic cfml. I don’t think it can work like this, because you are overwriting the code base, thus you are overwriting and resetting the application variables. At every refresh the variables will be already overwritten and gone. Really curious how this could have worked before in your old setup.

However… I’ve created this little testcase for you as a demonstration on how it could work. Just drop the files of the attached zip file into an empty webapps/root of a Lucee Express Version and run it. You’ll see that you can load the application settings even on behalf of an URL variable named “app” by opening http://localhost:8888/test.cfm?app=1 or
http://localhost:8888/test.cfm . You can do it also by binding it to cgi.http_host.

What you still would need to do is to adapt the varibale names of your apps pages, like changing application.someVarName to this.someVarName. But this is better than having lots of codebases.

I also can really recommend the following so highly valuable blogposts of @bennadel


Please find below my test case demonstration (1.0 KB)