Forms not working on your ColdFusion server? Size matters.

This post is more than 2 years old.

I've come across multiple people lately who have been bitten by this so I thought a quick blog post would be useful for my readers. If you've recently upgraded your ColdFusion server or patched it, you may find some forms return an error when submitted. Here is an example:

To cause this error, I simply created a form with 101 fields like so:

If you modify the loop to go to 100 instead of 101, it works fine. People using ColdFusion 10 or a recently patched ColdFusion 9 will encounter this.

The cause is a recent security fix. You can read the details here (Adobe ships patch for ColdFusion flaw that could lead to DoS attacks), but most likely you are only concerned about how to get around this.

In the ColdFusion 10 Administrator, under Settings, way at the bottom, you will find this new setting:

You can tweak this to a value that makes sense for your form. For folks using ColdFusion 8 and 9, you have to edit a bit of XML to handle this. Details may be found here: ColdFusion Security Hotfix APSB12-06.

A few minutes after I posted this blog post I tried a quick experiment. In ColdFusion 10, you can finally now take form fields of the same name and use this as an array. If you add this.sameformfieldsasarray = "true"; to your Application.cfc and post 2 form fields with the same name, their value in the form scope will be an array. I recommend this setting in general as a list (the normal behavior) cannot be reliably decoded. Turns out, if you use the same field name, you can post any number of form fields you want. I tried with 200, no problem. If you also do the sameformfield thingy, the values work just fine.

Raymond Camden's Picture

About Raymond Camden

Raymond is a senior developer evangelist for Adobe. He focuses on document services, JavaScript, and enterprise cat demos. If you like this article, please consider visiting my Amazon Wishlist or donating via PayPal to show your support. You can even buy me a coffee!

Lafayette, LA

Archived Comments

Comment 1 by Brian Thornton posted on 5/14/2013 at 6:09 PM

Great post

Comment 2 by Dinesh Kanwar posted on 5/14/2013 at 6:10 PM

And what about xml http requests? Are they effected by this too or not?

Comment 3 by Raymond Camden posted on 5/14/2013 at 6:11 PM

Dinesh, do you mean via AJAX? It is still a POST request, so yes. Btw, you guys posted quick. Be sure to read my Edit at the end.

Comment 4 by Will Swain posted on 5/14/2013 at 6:15 PM

I just figured this issue out yesterday. Was seeing it on a fresh 9.0.2 install. Particularly annoying since it just gives a 500 error and no further details.

Comment 5 by Dinesh Kanwar posted on 5/14/2013 at 6:19 PM

Regarding your edited post, I do not think having form fields with same name is practically viable. Is it? And I do not think I need any setting in app.cfc for that. Its forms default behavior to have values in list when you have same name form field. Just like a checkbox or radio. Well, you are probably the first person to know what has changed in adobe and if anything would have gone wrong related to this on my app, I always find only one place to go : Jedimaster's blog. Lucky this time I know in advance. :)

Comment 6 by Raymond Camden posted on 5/14/2013 at 6:23 PM

Dinesh: "I do not think having form fields with same name is practically viable. Is it?" Actually, they could have some value. Any time you need a set of related fields, for example, maybe kids names. Normally we do something like


etc. But having one field called kid is more convenient,simple.

"Its forms default behavior to have values in list when you have same name form field."

No, that's just how CF did it. PHP, for example, gave you an array. I'd rather use an array.

Comment 7 by Phillip Senn posted on 5/14/2013 at 6:45 PM

I saw sameformfieldsasarray mentioned in your latest CFWACK book and thought that I would use it, but on an existing application, you'd have to go through all the source code to see if it affects any pages with type="checkbox".

Q: Can you use sameformfieldsasarray for a single form?

Comment 8 by Raymond Camden posted on 5/14/2013 at 7:03 PM

As far as I know, no. But - you can get access to the PageServlet and the Form data and do something similar. I know I blogged about it a _long_ time ago.

Comment 9 by Michael Schmidt posted on 5/14/2013 at 8:12 PM

If my memory serves me correctly, the methods of getting multiple form fields as arrays has actually been "broken" by ColdFusion 10.

By broken the Automatic new method for converting form fields to array collapses empty elements so if you have a repeated row type that has a consistent form fields for that row if an text input or something is empty it will collapse and ignore it. The old method of getPageContext().getRequest().getParameterMap() doesn't work any more, and the only way i have been successfully able to get something to work is if i change the enctype on the form to multipart/form-data and use FORM.getPartsArray()

Comment 10 by Raymond Camden posted on 5/14/2013 at 8:17 PM

Wow, confirmed. It does collapse it. Of course, it does so for lists as well.

I'm curious what PHP does.

Michael, thanks for sharing this.

So my take away is this. If you have N fields and the lack of a field is important (it may not always be!), then you cannot use N fields with the same name. Period.

Comment 11 by Raymond Camden posted on 5/14/2013 at 8:32 PM

I had someone on Twitter test PHP. PHP does it right. Given 3 fields with the same name, and you leave field 2 blank, you will get an array with the second element empty, which is what it was obviously.

So - someone should file a bug report for this I think.

Comment 12 by MikeZ posted on 5/15/2013 at 6:44 AM

Nice to see that the resulting error is almost as useless as its counterpart in CF9 (where there seems to be no trace in the logs whatsoever).
The lack of a useful log entry made it harder than necessary to track down that parameter in the neo-runtime.xml

Comment 13 by Raymond Camden posted on 5/15/2013 at 2:27 PM

I believe (stress, believe) the useless error is to help hide the fact that this is trying to prevent a DDOS type attack.

Comment 14 by Will Swain posted on 5/15/2013 at 2:38 PM

Something more verbose, or just anything, in the cf logs files would be nice though. Almost impossible to debug.

Comment 15 by Raymond Camden posted on 5/15/2013 at 2:42 PM

Good point about the logs - that could certainly be more verbose. I'd encourage you to file a bug report on that.

Comment 16 by Peter Tilbrook posted on 5/15/2013 at 3:50 PM

This one crops up now and again. Recently (and no code changes) after a recent patch. Like Will says the error gives nothing at all away. Then I remembered the POST LIMIT and had to explain to SysAdmin how to fix it. Ditto on Will's suggestion for debugging. From memory nothing from the logs gave any indication. Sigh!

Comment 17 by Aaron Neff posted on 5/18/2013 at 10:08 AM

Hi Ray,

CF used to ignore this.sameformfieldsasarray="true", if setEncoding("form", ..) used certain encodings. I believe they fixed the issue for all setEncoding()'s encoding options, except for one of them. I mentioned the non-existent logging to them (forget if a bug was filed), but apparently the logging issue has not been fixed.