tracker issue : CF-3195811

select a category, or use search below
(searches all categories and all time range)

Exceeding the postParametersLimit limit won't log an error message.

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/

Reporter/Name(from Bugbase): Michael Zock / Michael Zock (Michael Zock)

Created: 05/22/2012

Components: Core Runtime

Versions: 9.0.1

Failure Type: Incorrect w/Workaround

Found In Build/Fixed In Build: 9.0.1 / CF11

Priority/Frequency: Normal / Some users will encounter

Locale/System: English / Win 2008 Server R2 64 bit

Vote Count: 1

Problem Description:
As explained in a recent hotfix has introduced a limit on the number of form fields that can be submitted in a single POST request.
But the exception that is supposed to be thrown is not logged in any of the files in the {cfroot}\log folder.

Steps to Reproduce:
Submit more form fields than are specified by the variable "postParametersLimit" in the {cfroot}\lib\neo-runtime.xml 

Actual Result:
A white page is returned, with HTTP Error code 500 and a content length of 26 bytes (according to Apache's access.log file).
Neither the CF logs nor the Apache logs will contain any useful information apart from Apache mere mention of the received request.

Expected Result:
Have an actually useful error message show up in the corresponding log file (e.g., "Number of post parameters exceeds the specified limit {value from config variable}.")

Any Workarounds:
Edit the neo-runtime.xml and deliberately specify a higher limit. Solves the immediate problem, but still won't log a useful error message to debug a situation like that.

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3195811

Deployment Phase:	Release Candidate

External Customer Info:
External Company:  
External Customer Name: michael_zock
External Customer Email:  
External Test Config: Fully updated 9.0.1 running in tandem with Apache on a Win 2008 R2 amd64 system.



Sorry, the correct URL is
Comment by External U.
19307 | May 22, 2012 07:28:23 AM GMT
Just wasted a good hour or two trying to debug an issue which turned out to be related to this bug...
Vote by External U.
19310 | February 06, 2013 10:50:42 AM GMT
In CF11 we log the message in server.log "Error","http-apr-8500-exec-4","12/17/13","19:41:14",,"POST parameters exceeds the maximum limit 100 specified in the server. You can modify the setting in Administrator Server Settings." (Comment added from ex-user id:yrr)
Comment by Adobe D.
19308 | December 17, 2013 08:43:43 AM GMT
It's great to hear that this is addressed in CF11. I'll note, for those on CF 8, 9, and 10, though, that the error is indeed "logged". Just not where you may expect it. It's in the console log, not the application.log or traditional CF logs. If running CF as a Windows service, that means it's in the coldfusion-out.log, which in CF9 and earlier would be in the [cf]\runtime\logs directory or [jrun4]\logs directory (depending on whether running CF as Standard/Server or multiserver). In CF10 it would be in the [cf10]\cfusion\logs. In *nix, it's in the cfserver.log (in the normal CF logs directory). All that said, I am really glad to hear of the fix in CF 11. Besides it now being logged in the more traditional logs (the server.log file, per the comment from Yashas at Adobe here), I hope it may mean also that it can be TRAPPED via error handling. That has been the greatest annoyance, to me, of this "security fix" (limiting number of form fields by default): even if one DID know it was logged in the console log, it could still not be trapped via error handling, so you had to look for it. Users got the error, and few knew about it. BTW, it's not so much that this "security fix" (limiting the number of form fields) is so much "new", as that many are only seeing it anew recently. It was actually introduced in a hotfix for CF8 and 9 that was created in 2012. But many did not apply security hotfixes back then, and the recent spate of vulnerabilities (many long-since fixed) have prompted people to apply them. Also, CF 902 and 10 automatically include such "security fixes". So many people may be experiencing the impact of this "change" only relatively recently. Anyway, great to hear that it will be still better going forward (just like it was nice that CF10 added a CF Admin field to manage this setting for the max number of form fields.) And FWIW, it's perhaps worth noting for some readers that this implementation in 2012 of the limitation of form fields was not unique to ColdFusion. It was a vulnerability that hit many application servers. This was just Adobe's response to it. Of course, many ask "ok, so what number can I set it to that's high enough to avoid errors (because we have large forms) but not so high that we expose ourselves to the vulnerability?" I've never heard any good answer to that question. As always, security fixes tend not to expose details about the vulnerability, to avoid people trying to cause it on servers that may not yet have the fix.
Comment by External U.
19309 | March 31, 2014 09:08:17 AM GMT