Skip navigation
dpstucson
Currently Being Moderated

APSB12-06 and errors

Mar 15, 2012 11:06 AM

Since applying the latest security patch I am receiving the below events and it has broken two of our apps.

03/15 11:54:38 error ROOT CAUSE:

coldfusion.filter.FormScope$PostParametersLimitExceededException: POST parameters exceeds the maximum limit specified in the server.

    at coldfusion.filter.FormScope.parseQueryString(FormScope.java:397)

    at coldfusion.filter.FormScope.parsePostData(FormScope.java:346)

    at coldfusion.filter.FormScope.fillForm(FormScope.java:296)

    at coldfusion.filter.FusionContext.SymTab_initForRequest(FusionContext.j ava:377)

    at coldfusion.filter.GlobalsFilter.invoke(GlobalsFilter.java:33)

    at coldfusion.filter.DatasourceFilter.invoke(DatasourceFilter.java:22)

    at coldfusion.filter.CachingFilter.invoke(CachingFilter.java:62)

    at coldfusion.filter.RequestThrottleFilter.invoke(RequestThrottleFilter. java:126)

    at coldfusion.CfmServlet.service(CfmServlet.java:200)

    at coldfusion.bootstrap.BootstrapServlet.service(BootstrapServlet.java:8 9)

    at jrun.servlet.FilterChain.doFilter(FilterChain.java:86)

    at coldfusion.monitor.event.MonitoringServletFilter.doFilter(MonitoringS ervletFilter.java:42)

    at coldfusion.bootstrap.BootstrapFilter.doFilter(BootstrapFilter.java:46 )

    at jrun.servlet.FilterChain.doFilter(FilterChain.java:94)

    at jrun.servlet.FilterChain.service(FilterChain.java:101)

    at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:106)

    at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42)

    at jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java: 286)

    at jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java: 543)

    at jrun.servlet.jrpp.JRunProxyService.invokeRunnable(JRunProxyService.ja va:203)

    at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.j ava:428)

    at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)

 

javax.servlet.ServletException: ROOT CAUSE:

coldfusion.filter.FormScope$PostParametersLimitExceededException: POST parameters exceeds the maximum limit specified in the server.

    at coldfusion.filter.FormScope.parseQueryString(FormScope.java:397)

    at coldfusion.filter.FormScope.parsePostData(FormScope.java:346)

    at coldfusion.filter.FormScope.fillForm(FormScope.java:296)

    at coldfusion.filter.FusionContext.SymTab_initForRequest(FusionContext.j ava:377)

    at coldfusion.filter.GlobalsFilter.invoke(GlobalsFilter.java:33)

    at coldfusion.filter.DatasourceFilter.invoke(DatasourceFilter.java:22)

    at coldfusion.filter.CachingFilter.invoke(CachingFilter.java:62)

    at coldfusion.filter.RequestThrottleFilter.invoke(RequestThrottleFilter. java:126)

    at coldfusion.CfmServlet.service(CfmServlet.java:200)

    at coldfusion.bootstrap.BootstrapServlet.service(BootstrapServlet.java:8 9)

    at jrun.servlet.FilterChain.doFilter(FilterChain.java:86)

    at coldfusion.monitor.event.MonitoringServletFilter.doFilter(MonitoringS ervletFilter.java:42)

    at coldfusion.bootstrap.BootstrapFilter.doFilter(BootstrapFilter.java:46 )

    at jrun.servlet.FilterChain.doFilter(FilterChain.java:94)

    at jrun.servlet.FilterChain.service(FilterChain.java:101)

    at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:106)

    at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42)

    at jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java: 286)

    at jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java: 543)

    at jrun.servlet.jrpp.JRunProxyService.invokeRunnable(JRunProxyService.ja va:203)

    at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.j ava:428)

    at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)

 

    at coldfusion.monitor.event.MonitoringServletFilter.doFilter(MonitoringS ervletFilter.java:70)

    at coldfusion.bootstrap.BootstrapFilter.doFilter(BootstrapFilter.java:46 )

    at jrun.servlet.FilterChain.doFilter(FilterChain.java:94)

    at jrun.servlet.FilterChain.service(FilterChain.java:101)

    at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:106)

    at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42)

    at jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java: 286)

    at jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java: 543)

    at jrun.servlet.jrpp.JRunProxyService.invokeRunnable(JRunProxyService.ja va:203)

    at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.j ava:428)

    at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)

 

03/15 11:54:38 error (JRun Service: ProxyService [jrun.servlet.jrpp.JRunProxyService@4c27d5bc]) JRunPRoxyServer.invokeRunnable:

java.lang.IllegalStateException

    at jrun.servlet.JRunResponse.getWriter(JRunResponse.java:205)

    at jrun.servlet.JRunResponse.sendError(JRunResponse.java:597)

    at jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java: 328)

    at jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java: 543)

    at jrun.servlet.jrpp.JRunProxyService.invokeRunnable(JRunProxyService.ja va:203)

    at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.j ava:428)

    at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)

 
Replies
  • Currently Being Moderated
    Mar 15, 2012 1:56 PM   in reply to dpstucson

    Two things to check:  1) make sure that you followed the installation instructions properly, there are a few jar files that you need to delete from the updates dir - if you missed that step you might see that error.  2) Is the page where you get this the result of a large form post, eg over 100mb or over 100 form fields? If so then you need to adjust settings, this is described in the KB article associated with the hotfix.  Hope that helps

     

    --

    Pete Freitag

    http://hackmycf.com/ - Is your ColdFusion Server Secure?

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 16, 2012 3:23 PM   in reply to dpstucson

    But the key question was: is the page that’s failing doing a post? And does the size exceed the limits? That’s the change that fix introduces.

     

     

     

    /charlie

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 20, 2012 8:12 AM   in reply to Charlie Arehart

    Given that the error message you've posted includes "PostParametersLimitExceededException" you might try editing your neo-runtime.xml file adding the line below:

     

    <var name='postParametersLimit'><number>100.0</number></var>

     

    See: http://helpx.adobe.com/coldfusion/kb/coldfusion-security-hotfix.html

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 21, 2012 12:52 PM   in reply to JR \"Bob\" Dobbs

    I am getting reports from users about this problem as well, andI have verified that this line is also in our xml files, per the hotfix article: 

     

    <var name='postParametersLimit'><number>100.0</number></var>

     

    First of all, I assume this number means "100MB."   There's no way the form being submitted is submitting 100MB worth of data; there's no file upload and there's not that much data entered into the form.

     

    I am going to be rebooting all affected servers and will report back with my findings, but I may need to resort to rolling back this hotfix.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 21, 2012 1:05 PM   in reply to Marc Funaro

    Ah wait... I bet you're going to tell me that the number is NOT representing "100MB" but "100 form field parameters" (like the var name says) in which case this form may very well have over 100 fields.  I've adjusted upwards accordingly, we'll see if that's what the deal is.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 22, 2012 7:50 AM   in reply to Marc Funaro

    Folks, there is talk among some that seems to be concluding that this security hotfix presumes to rely on elements implemented in Cumulative hotfix 3 (for 8.0.1. Have not heard similar discussions for other versions yet.) If you have not added that, consider it. If you have previously added it, make sure you didn’t delete the CFH3 jar (while deleting other jars, per the technote.)

     

    For more on this issue, as well as some thoughts on the hope for hotfix challenges to perhaps be fixed in the future (even in CF 8 and 9, separate from what’s coming in CF10), see my discussion in another thread on the same topic (of problems with this security hotfix) that I just posted:

     

     

     

    http://forums.adobe.com/message/4282942#4282942

     

     

     

    /charlie

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 22, 2012 11:16 AM   in reply to dpstucson

    JR/"Bob" - is right.  You need to modify the "post parameters limit" variable in the neo-runtime.xml file:

     

            <var name='postParametersLimit'><number>100.0</number></var>

     

          But increase it from 100.0 to something "much" bigger.  I increased mine to 5000 due to my form processing requirements.

     

           This is the "number" of input parameters being posted from the form not the size.

     

          The post "size" variable is also in the neo-runtime.xml file as:

     

         <var name='postSizeLimit'><number>100.0<number></var>

     

          The post Size limit variable can be set from the Coldfusion Admin GUI but the post  Parameters limit has to be change in the xml and Coldfusion restarted.

     

           It appears that the APSB12-06 patch started enforcing the post Paramters limit setting.

     

           This corrected my problem but I am also probably going to redesign my page to use JQuery to reduce the number of input parameters on the form.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 27, 2012 6:39 PM   in reply to Peter Freitag

    this kind of worked for me,

     

    1. i redid the update follwing the steps closely, it worked just when posting forms to db resulted in the error

    2. changing the neo-runtime.xml didnt do any good.

    3. deleting the .jar files int the /li/updates/ folder did the trick,

     

    The thing is in the instructions by adobe, it states a few files to delete the .jar files from the updates folder but it specifically spcifies the names of them so i had left my hf801-005.jar in there since it was not on the list specified by adobe.

     

    After deleting this, its working so far.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 28, 2012 5:57 AM   in reply to tanshul

    Bear in mind that the hf801-*.jar files are the hotfix patch files.  If you delete the hf801-00005.jar file you are removing the hotfix.

     

    Message was edited by: JR \"Bob\" Dobbs

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 28, 2012 10:12 AM   in reply to dpstucson

    Still no luck for me. I modified the neo-runtime.xml file as instructed. I also did as Charlie suggested and made sure I had Cummulative Hotfix 3 installed, which actually fixed some other problems I had, but I still have the "POST parameters exceeds the maximum limit specified in the server" error.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 28, 2012 10:34 AM   in reply to dpstucson

    Just tried installing Cumulative Hotfix 4 to see if it fixed it, it didn't.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 28, 2012 10:58 AM   in reply to dpstucson

    Noticed the server I was working on didn't have either CHF 1 or 2 installed, so installed those as well. Still didn't solve the problem. Not feeling very lucky today.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 28, 2012 11:15 AM   in reply to dpstucson

    tmessier - Do you get the "POST parameters exceeds the maximum limit" on every web page?

     

             The defaut size is 100 input parameters.  You can view the source of your page, right click on page - view source, and see how many "<input" parameters are on the page.  Remember you should have two "post" variables in the neo-runtime.xml file.  One specifies the size in MB of the page (or file being uploaded) and the other specifies the number of parameters that can be posted.  Make the "postParametersLimit" variable very big "9999.0" and see if this corrects the problem.  

     

              As a side not can someone tell me how to "paste" text into this forum reply box.  My "paste" button is grayed out.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 28, 2012 11:33 AM   in reply to dpstucson

    I got it working, it was totally my fault. I searched my neo-runtime.xml file for postParametersLimit and found nothing so I added it after postSizeLimit per the instructions. Turns out my file did have a postParametersLimit in it, but it didn't come right after postSizeLimit so I didn't notice it and I must have searched for the wrong thing (probably forgot the "s" in "Parameters"). So after removing the duplicate entry, everything worked fine. Felt stupid wasting an hour on this, but it could have been worse if I hadn't spotted the duplicate!

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 28, 2012 8:27 PM   in reply to tmessier

    Good to hear you resolved it. But you should now remove those CHF1 and 2 jar files you added (per your note in this thread at http://forums.adobe.com/message/4297879#4297879), when you had CHF 3 already. They are cumulative. You do not need the earlier ones if you install the later ones. And in that you also said in another message that you added CHF 4, you should remove the CHF 3 jar. But be careful to ONLY remove those that start with chf (for 1, 2, and 3), not any for HF (individual hotfixes) unless a technote tells you to remove them.

     

    /charlie

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 30, 2012 9:56 AM   in reply to tmessier

    One other thought on this: one other conclusion from this is that people should not “just add” the line about postParametersLimit if they are finding this thread to solve the problem.

     

    They should first check if the string is already in the neo-runtime.xml file. To be clear, it’s not there unless and until someone reads the technote (for the hotfix) and adds it. (the postsizelimit has been there at least since CF7, and is controlled via a setting on the CF Admin Settings page).

     

    But it could be that you (dear reader of this thread) may be finding this thread in order to “solve” the problem of your now getting an error when trying to post a form submission. And someone else on your server may have applied the HF which imposed the new limitation (of number of form fields that can be posted, as a security fix).  That person applying the fix may not have raised the postParametersLimit value high enough for your specific application’s needs.

     

    So again, don’t “just add the lines” for postParametersLimit. That’s what the technote says to do when you are applying the hotfix. The lesson to be learned from the experience of some others in this thread is that if you are NOT the one applying the hotfix, don’t mistakenly “add the lines” for postParametersLimit. Check first if it’s there (from someone having applied the hotfix), and if so, update the value instead.

     

    Finally, I’m pretty sure changing that value in that file will require a restart of CF for it to take effect, at least until Adobe updates the Admin so that you change it instead in the interface, where they could cause the xml file to be reloaded.

     

     

     

    /charlie

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 12, 2012 9:31 AM   in reply to Charlie Arehart

    I have a form designed by one of our partners that has exactly 101 form elements. 

     

    Something I am running into is that after editing neo-runtime.xml & performing a restart, all seems ok, until...  Until I make a change via the CF Admin.  After that, the <var name='postParametersLimit'><number>xxx.0</number></var> line is removed.

     

    According to http://helpx.adobe.com/coldfusion/kb/coldfusion-security-hotfix.html, "We are not exposing this setting in ColdFusion Administrator console, but this limit can be easily changed in neo-runtime.xml file."  Thus, I believ by not exposing it via the CF admin console, that setting is ignored upon any console cahnges/updates.  Not very helpful at all.  Tie another string around my finger for things to remember to do when I perform task xyz.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 17, 2012 4:39 AM   in reply to In_Finite

    It may be possible that the reason it’s not written when you edit is that it’s possible that they changed the Admin code to write it (even without exposing it in the interface), but perhaps while applying this or another update you did not properly update the CFIDE directory that underlies your CF Admin. I see this happen often, as people sometimes have more than one CFIDE, and might pick the “wrong” one. Start by checking what’s defined in the CF Admin Mappings page.

     

    But that’s not enough, sadly. What matters more is where the docroot is for the website in the web server you use to run the CF Admin. If using a port (like 8300, 8500, etc) then you’re likely using CF’s built-in web server, and its docroot (and place to find and update the CFIDE) is generally Re: APSB12-06 and errors\wwwroot.  If using IIS or Apache, then it’s wherever the docroot is for the website you’re using there.

     

    Some people have duplicated their CFIDE and placed copies in different docroots, whether for use by the code that their CFML creates (some of which calls back to the server for some subdirs of CFIDE) or simply because they wanted be able to access the CFAdmin in different web sites. Sure, they could have created virtual directories instead, but many go the simple route. And so when hotfixes are applied that require updating the CFIDE, the person doing that may do only the “one” they think is in use by CF, when in fact it could be many.

     

    And that then could leave you in the state you’re in. Just a guess. Could be wrong. Just an idea, if it may help.

     

    /charlie

     

    PS If anyone would wonder, “well if they CF Admin is accessed by way of different CFIDE dirs in different web sites, then wouldn’t that mean I’d see different results saved in the CF Admin if accessed these different ways”, the answer is “no”. The CF Admin writes its results back to the server, typically in Re: APSB12-06 and errors\lib\neo-*.xml files. It does not write back to the CFIDE dir itself. So, again, some people can be suffering from this problem of different sites using subtly different CFIDE codebases, and they may not readily notice it at all, until quirky things like the below might happen.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 17, 2012 1:28 PM   in reply to Charlie Arehart

    Charlie,

     

    Thnx for the reply, and I think you nailed it on your opening statement. "It may be possible that the reason it’s not written when you edit is that it’s possible that they changed the Admin code to write it (even without exposing it in the interface)".  I failed to heed the warning of an earlier post and there may have already been an entry with a value of 100.  I placed mine directly after the postSizeLimit and later found it missing.  Knowing that the file is written in whatever order the server wants to place the elements, I went searching for 'postParametersLimit'  and discovered '<var name='postParametersLimit'><number>100.0</number></var>'.

     

    This sort of demosntrates that the Admin code does placed it with a default value of 100, but not neccessarily where I expected to find it.  I reset the value to what I wanted, restarted the server, and then made several edits via the CF Admin, thus proving I was expeiencing an ID 10 T error.

     

    Without derailing the topic:  With regards to the whole /CFIDE/ topic, my practice has been to create two folders for each server instance.  One that is a target for the sites served by said instance that does not contain the adminapi and similar folders, thus not exposing the admin api, that is a virtual fodler target for said sites.  The other folder is targeted by an internal only web site for administering each server instance, thus only exposing the CF Admin thru a site that can only be reach by LAN clients.  This makes managing updaets a bit easier.  Curious what others do.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 17, 2012 5:47 PM   in reply to In_Finite

    Glad to hear that you solved it.

     

    As for your approach to managing the CFIDE directory for various uses, there are lots of ways to solve things, each with their pros and cons in terms of maintainability, security, etc. Not really any one right way. It would be a useful blog entry for someone to outline the many approaches and their implications, in both the near and long term (meaning with respect to applying updates, etc.)

     

     

     

    /charlie

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 19, 2012 4:55 AM   in reply to Charlie Arehart

    This hotfix is causing crazy problems and I think part of the issue is the description of the fix for the forms.  It tends to imply that the default value is 100 and if you need more, feel free to change it.  The default value is in fact 15, so I think everybody will need to change this.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 19, 2012 9:04 AM   in reply to Stephen.M.Walker

    I just went and looked at a fresh isntall withonly the update applied and no changes to neo-runtime.xml

     

    <var name='postSizeLimit'><number>100.0</number></var>

    <var name='webserviceLimit'><number>5.0</number></var>

    <var name='queueTimeout'><number>60.0</number></var>

    <var name='timeoutRequestTimeLimit'><number>60.0</number></var>

    <var name='slowRequestTimeLimit'><number>30.0</number></var>

    <var name='flashRemotingLimit'><number>5.0</number></var>

    <var name='postParametersLimit'><number>100.0</number></var>

     

    I'm lost as to where you came up with 15, but curious.  My biggest problem was haste, oversight, not paying attention to the previous warnings in this thread.  The docs mention to jump to Section 2 if certain conditions apply.  This caused me to not pay attention to the Notes section.  The notes also mention that you want to place the 'postParametersLimit' right below 'postSizeLimit'.  Thus, not finding it there, I believed it wasn't yet in the file.

     

     

     

    -Dan

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 19, 2012 9:56 AM   in reply to In_Finite

    If the setting has been there, it was set at 15.  I am finding many of our servers don't have the setting at all.  Just seems a bit odd.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 20, 2012 4:23 AM   in reply to Stephen.M.Walker

    This needs to be a per application setting and not just a global setting.  We have forms with 300 form fields and from a security perspective, that shouldn't be the server baseline.  Hopefully, CF10 will address this.  Since this is called postParameterLimit, does anybody know if processing cfparam or cfqueryparam gets included in the count?  If not, why not change the name to formFieldLimit?

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 20, 2012 8:03 AM   in reply to Stephen.M.Walker

    Stephen, you won’t find this setting there, until you apply this fix.

     

    Like Dan, I’m curious where you’re getting your 15 from. You seem quite confident. When you say “if the setting has been there, it was set at 15”. So do you mean, in some of your servers, in that xml file, you find that setting, and it’s set at 15? You or someone there had to have put it there, from everything I know about this issue.

     

    /charlie

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 20, 2012 8:09 AM   in reply to Stephen.M.Walker

    Stephen, no, it has nothing to do with those other “parameters”. That word is used generically throughout CFML and indeed IT in various ways (good ol’ parameterexists was the way to test for variable existence before isdefined). I suspect in this case the engineer picking it did so without any consideration of the use of the word elsewhere in CFML.

     

    As for the name of the xml element, well, the hotfix is about form submissions, via an http post method, so the “formpost” part is at least technically correct, if perhaps not as user friendly as it could be. And then they needed a metric to count how many of those per request would be permitted, and they chose “parameter”. They could have chosen “count”, or perhaps others. So yes they could have picked “formfieldlimit”, or one might argue that even “formfieldcountlimit” would be more accurate. Or “formfieldmaxcount”, and so on.

     

    But the name is a pretty low-priority issue, I think, and I doubt they’d revisit it. Just one person’s opinion. We’ve just not seen much from Adobe on this issue here, so I’m just offering at least one reply for you sine you feel the matter deserves consideration. Hope that’s helpful.

     

    /charlie

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 20, 2012 12:06 PM   in reply to Charlie Arehart

    Charlie,

     

    We applied the hotfix to all of our servers (10) and 2 had a value of 15 and the rest didn't even have the setting.  I am the only one who has attempted to modify the neo file, so I am fairly confident in my findings.  We ended up rolling back to hotfix 3 on most of the servers because of the high form field count.  As far as the naming, it is a very low priority issue.  I still think it should be an application level setting (this.postParametersLimit) to allow admins to set a low default value and overide on a per application basis.

     

    As always, thanks for taking the time to respond.

     

    Cheers,

    Steve

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 20, 2012 12:27 PM   in reply to Stephen.M.Walker

    Fair enough, Stephen, and thanks for the kind regards. But do you understand that the setting can only get there if you put it there (whether it’s there at all, or there with a value of 15)?

     

    This is discussed in note 5 in the technote, http://helpx.adobe.com/coldfusion/kb/coldfusion-security-hotfix.html. You just seem to be asserting that it got there somehow another way. It cannot. And if it’s not there, than as the note indicates, the default is 100. You only need add the xml element if you want to change that.

     

    As for hoping it might be made more app-level instead, I can appreciate the value in that. We can hope that the Adobe engineers will see this and consider it. But you may be better off filing that as an enhancement request, at https://bugbase.adobe.com/.

     

    Hope that’s helpful.

     

     

     

    /charlie

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 20, 2012 12:00 AM   in reply to Charlie Arehart

    We encountered the "coldfusion.filter.FormScope$PostParametersLimitExceededException: POST parameters exceeds the maximum limit specified in the server." error after a fresh installation of ColdFusion 9.0.2 (the edition without Verity).

     

    The CF9 Administrator does not have a setting for this option (whereas the CF10 Administrator does), so we edited the neo-runtime.xml file to increase the parameter to 5000.0 as suggested above and that solved the issue for us.

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 20, 2012 10:05 AM   in reply to Benjamin Reid

    Ben - actually I think 9.0.2 does now have a setting for this in the ColdFusion administrator, it was listed in the release notes, I have not yet tried 9.0.2 so I can't confirm.

     

    --

    Pete Freitag

    Foundeo Inc. | HackMyCF.com

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 21, 2012 1:45 PM   in reply to Peter Freitag

    We can all wish it was so, Pete, but sadly, no.

     

    http://helpx.adobe.com/coldfusion/release-note/coldfusion-9-0-update-2 .html#ChangestoColdFusionAdministrator

     

    “The setting is not exposed in the ColdFusion Administrator console, but it can be modified in the neo-runtime.xml file.”

     

    Perhaps it may be offered in another updater some day.

     

    /charlie

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 21, 2012 2:12 PM   in reply to Charlie Arehart

    Thanks for checking/clarifying charlie - I obviously misread that note as The setting is *now* exposed...

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 21, 2013 5:32 AM   in reply to Charlie Arehart

    Does anyone know if it's possible to read this setting procedurally, even with undocumented APIs? Our support staff has access to a code execution environment on some remote servers, and wants to be able to check it.

     

    Thanks,

    Dave

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 25, 2013 8:13 PM   in reply to dmerrill

    Yes, Dave, by way of the AdminAPI, which is available in both Standard and Enterprise editions of CF. See the runtime.cfc’s getRuntimeProperty method.  Here’s one very simplistic example of code to get it: just change it to your user CF Admin password.

     

     

     

     

     

    /charlie

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 26, 2013 6:48 PM   in reply to Charlie Arehart

    Thanks for getting back, and for the general steer, but the code in your post got eaten. I tried the code below (which probably also won't come through), but the result is undefined. My guess is that all I need is the right name for that parameter, assuming it's readable via the API. If you or anyone else knows where I could find docs or other info on this, it'd be great.

     

    Dave

     

    <cfscript>

        createObject("component","cfide.adminapi.administrator").login("trian gle99");

        runtime = createObject("component","CFIDE.adminapi.runtime");

        prop = runtime.GetRuntimeProperty("postParametersLimit");

    </cfscript>

    <cfdump var="#prop#">

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 26, 2013 7:21 PM   in reply to dmerrill

    Bummer. I hate when that happens (that forums or mailing lists hide or munge code when we offer it.) Here it is again, without the opening and closing brackets (and sure, it could be done as pure CFSCRIPT as well):

     

    cfset createobject("component","CFIDE.adminapi.administrator").login('youra dminpw')

     

     

     

    cfdump var="#createobject("component","CFIDE.adminapi.runtime").getRuntimePr operty("PostParametersLimit")#"

     

    Curiously, yours came through fine (did you enter yours in the web-based forum interface? I am replying by email), and I see that your code is essentially the same. It worked for me, so I would say that if the value is empty for you, that means it’s NOT defined (in the neo-runtime.xml), which of course it’s not by default in CF 9. You have to add it. If you may feel you did add it, then I would propose you may have added it in a way that it’s not being recognized. You have to be sure to enter the XML just as offered in the technote. It’s best to find the one for postsizelimit, and duplicate it, and then modify the duplicated version.

     

    Hope that helps.

     

     

     

    /charlie

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points