Problem with form.FieldNames

[User_Since_V1_5]

I have a problem with a form.

The form has an action page. At the top of that page is the following code:

<cfif NOT #IsDefined("form.FieldNames")#>
    <cflocation addtoken="no" url="my form page">
</cfif>

All of the fields on my form page have default values. These values are kept in a session struct and get defaulted in application.cfm.On the action page, the session values then get updated according to what the user has entered on the form.The user then gets taken, via cflocation, to a page that shows what he/she has just entered, for verification purposes.

Straightforward. And many, many thousands of people have submitted the form without incident. But many others have submitted the form, only to be immediately returned to the form page with all values defaulted (as one would expect to happen if form.FieldNames is not defined).

Has anyone seen behavior like this? Can anyone suggest a solution?

Key facts:

1. The form definitely uses POST.

2. The form does not contain any fields whose names would cause a problem in form.FieldNames, eg. names ending in _required, _date, etc.

3. Version of CF is 7, running on Windows Server 2003 with 2G memory. JVM heap is 512M.

4. When this happens, the load is high (as I said -- many, many thousands of successful submissions occur).

5. This doesn't appear to be a browser issue.

Thanks in advance for any help.

[Steve Sommers]

I rarely use form.fieldNames and never like this. Instead, I set a hidden form field like action="UPDATE" and then check this value:

<cfparam name="form.action" default="" />

...

<cfif form.action EQ "UPDATE">

     /* do whatever */

</cfif>

or as in your example:

<cfif form.action EQ "">
     <cflocation addtoken="no" url="my form page">
</cfif>

To go a little further, I also incorporate a fusebox technique to merge the URL and FORM scope into a single attributes scope:

/* usually in application.cfm or cfc */

<cfif NOT IsDefined("attributes")>

     <cfset attributes=StructNew() />

</cfif>

<cfif IsDefined("FORM")>

     <cfset StructAppend(attributes,FORM,false)>
</cfif>

<cfif IsDefined("URL")>

     <cfset StructAppend(attributes,URL,false)>
</cfif>

Then modify the original to:

<cfparam name="attributes.action" default="" />

...

<cfif attributes.action EQ "UPDATE">

     /* do whatever */

</cfif>

The reason I do it this way is that then it is easy to add simple links for DELETE or CREATE:

<a href="myFormActionPage.cfm?action=DELETE&id=123">Delete this entry</a>

<a href="myFormActionPage.cfm?action=CREATE">Create a new entry</a>

[User_Since_V1_5]

This technique looks helpful but it won't really solve my issue. However that <cflocation> gets triggered, it produces a lot of resentment. The user has just taken the time to fill in the form -- and he/she then gets returned to it with all entries gone and nothing processed. Successful processing of the form requires looping through form.FieldNames. The test is present only to prevent people from executing the action page directly.

I need to figure out why this is happening and deal with it. My only clue is that this issue occurs under high load, so my hunch is that this is memory-related. Are there reported problems with form.FieldNames in that situation? Is there a 'safer' (ie, more reliable) way for ColdFusion to process form entries?

[cfjedimaster]

While I'm not aware of any load issues in this regard, I normally use

this to check for an empty form:

and I normally use struct functions to loop through form fields

<cfloop item="key" collection="#form#"

[User_Since_V1_5]

I assume you mean StructIsEmpty(form)? Yes, but again, the issue of why remains.

Are you saying that there might be cases where the form struct is NOT empty (and therefore could be looped over), but where its FieldNames key does not exist? In that situation, my technique fails but yours succeeds, and I'm eternally grateful. But if there are situations where the user can successfully submit the form and yet end up with a totally empty form struct, both techniques fail -- and I need to know the cause(es) of those situations.

[cfjedimaster]

--

===========================================================================

Raymond Camden, ColdFusion Jedi Master

Email : ray@camdenfamily.com

Blog : www.coldfusionjedi.com

AOL IM : cfjedimaster

[Adam Cameron.]

cfjedimaster wrote:

--

====================================================================== =====

Raymond Camden, ColdFusion Jedi Master

Email : ray@camdenfamily.com

Blog : www.coldfusionjedi.com

AOL IM : cfjedimaster

I agree with Ray on this one.

--

Adam

[User_Since_V1_5]

You must also be a jedi master. Enlightenment seek I, to make the unseen seen.

[cfjedimaster]

Adam is my Padawan. If he says no, he is just being modest.

[User_Since_V1_5]

Seriously, though, what did you intend to write?

[cfjedimaster]

Eh? If that is to me - I don't know what you mean. If you mean Adam,

his reply was at the bottom:

I agree with Ray on this one.

--

Adam

[User_Since_V1_5]

Your reply at 9:43AM is empty except for your email signature. Is that not what you see at http://forums.adobe.com/message/3223173#3223173 ??

[Steve Sommers]

Actually it would eliminate any possible CF issue specific to the form.fieldNames variable (but I think the chance of this would be low anyway). Another plus with this method is that having a hard-coded hidden variable give you an absolute known starting point -- you know the field wil exist if the form is posted.

Anyway, my suggested code is really only eliminating possible causes and help with diagnosis. As to guess what is acutally causing your issue, I would look at all CFLOCATION calls. Is it possible you have some code in application.cfc or cfm that detects certain pages or actions and makes certain they are using http: or https: accordingly and using CFLOCATION to bounce the user to the proper protocol? If so, this could cause your symptom.

Another guess, are you using SSL and specifying HTTPS: for this form post? If not, depending on the browser and security setting of the browser, it may be preventing the form data to be posted.

[User_Since_V1_5]

You wrote:

are you using SSL and specifying HTTPS: for this form post? If not, 
depending on the browser and security setting of the browser, it may be 
preventing the form data to be posted.

The form page is definitely addressed as https://<myformpage>. The action on the form is just action="/<myformaction>" -- which would still remain at https://.....

[Dan_Bracuk]

I've seen something similar.  The user would properly submit the form and the page would process.  Then, with no input from the user, the page would reload with no form scope whatsoever.

Check your http logs to see if this is happening to you.  You might want to mail yourself the cgi scope, form scope, and timestamp before re-directing so you know where in the logs to look.

[cfjedimaster]

Ugh, must have been the email interface. Let's try this again:

>
> I assume you mean StructIsEmpty(form)? Yes, but again, the issue of *why* remains.

Isn't that what I typed?

And yeah - the why is mysterious. I'd see if you can find out a common
browser type.

> Are you saying that there might be cases where the form struct is NOT empty (and therefore could be looped over), but where its FieldNames key does not exist? In that situation, my technique fails but yours succeeds, and I'm eternally grateful. But if there are situations where the user can successfully submit the form and yet end up with a totally empty form struct, both techniques fail -- and I need to know the cause(es) of those situations.

I've seen that fairly recently:
http://www.coldfusionjedi.com/index.cfm/2010/10/15/Diagnosing-an-error--Form-entries-are-incomplete-...

[User_Since_V1_5]

You typed it, but it didn't show up either.

This is my first real lead!. Thanks; I'll post a followup once I've had a chance to investigate further.

[User_Since_V1_5]

In the blog post that you referenced, you wrote

I then realized the issue. ColdFusion wasn't populating form.fieldnames.
 If he had just dumped the form scope itself it would have worked. So 
for some reason, when a form validation error occurs, form.fieldnames 
will not exist.

I find this extremely helpful, though still puzzling. I've scoured the code. There is definitely no use of 'reserved' fieldnames such as xxx_required, xxx_date, etc. I did find this:

<cfset year_validation_range = "#variables.year_low#" & "," & "#variables.year_high#">

but the variable in question is referenced throughout as #variables.year_validation_range#. So unless CF is confusing its scopes, this can't be the source of the issue. And anyway, why would the issue occur for some users but not for others (the vast majority)? Furthermore, I don't think the problem is browser related -- I never saw it in FireFox 3.6/PC, while a colleague at a different location did see it in FireFox 3.6/PC (admittedly, different subversion numbers).

I keep coming back to the issue of memory load and the idea that CF might be having trouble building the form struct (which includes the fieldnames key) for some users, under heavy load. If that's the case, would I still have a potential problem if I altered the code so it loops over the scope to evaluate all key/value pairs other than form.fieldnames? (I'm going to do that anyway -- but it would be nice to know whether to still expect trouble.)

At least this gives me something to try. Any additional thoughts will be greatly appreciated.

[User_Since_V1_5]

Still investigating this, and no closer to an answer. I have run into something quite interesting, though.

At the top of my action page I've placed

<cfif #IsDefined("form")#>

    <cfloop collection="#form#" item="key">

        <cfoutput>#key# ---- #form[key]#<br></cfoutput>

    </cfloop>

<cfelse>

    <cfoutput>Form submission not defined</cfoutput>

</cfif>

<cfabort>

and when I submit the form, I get all expected values including the list of fields stored in the FieldNames key. Sitting on that page, I tell FireFox to reload (right click -- Reload), which it obediently does after warning me that it must re-submit the form. The list comes back as before -- but in a different order. I can repeat this action, and each time the list comes back in a different order. Is that normal behavior?

If I then go to the browser's address line, highlight the address, and simply press Enter, I see....nothing. Not 'Form submission not defined', as I was expecting, but nothing; a blank page. Is that normal behavior?

Also, I found this reference:

     http://www.jensbits.com/2009/07/29/coldfusion-dropping-losing-or-resetting-session-variables-and-cfi...

and I wonder if the issue discussed there might apply somehow to the form scope as well as the session scope?

[ilssac]

User Since V1.5 wrote:

and when I submit the form, I get all expected values including the list of fields stored in the FieldNames key. Sitting on that page, I tell FireFox to reload (right click -- Reload), which it obediently does after warning me that it must re-submit the form. The list comes back as before -- but in a different order. I can repeat this action, and each time the list comes back in a different order. Is that normal behavior?

I don't know if it is normal, but I have always assumed that form order is random.  I can not imagine why just resubmitting with the same browser to the same web server would change the order.  But I have always assumed that different users using different clients on different operating systems, that I should NEVER assume that form fields will be in any certain order.

User Since V1.5 wrote:

If I then go to the browser's address line, highlight the address, and simply press Enter, I see....nothing. Not 'Form submission not defined', as I was expecting, but nothing; a blank page. Is that normal behavior?

Yes this would be the expected behavior.  ColdFusion always has a form scope.  So your isDefined() function is always going to return true and then your loop is going to loop over an empy structure and generate no output, thus an empty page.  The proper test would be structIsEmpty() OR structCount() EQ 0.

[existdissolve]

If I then go to the browser's address line, highlight the address, and simply press Enter, I see....nothing. Not 'Form submission not defined', as I was expecting, but nothing; a blank page. Is that normal behavior?

Try dumping the form scope where you think it should not exist. When I try your example, I can dump the form scope simply by browsing to my page--no form submission required.  The form scope is defined, but since you are merely checking for its existence (and not whether it actually contains anything), it never gets to your "else" statement.

[insuractive]

Sounds to me like some of your users might be losing session scope - especially since your data is being stored in session variables and only SOME of them are experiencing the problem.  Could be a problem with browser/cookie persistence or server P3P file?  It seems more likely that is probably the culprit than the Form.FieldNames not showing up.

[User_Since_V1_5]

insuractive wrote:

Sounds to me like some of your users might be losing session scope - especially since your data is being stored in session variables and only SOME of them are experiencing the problem.  Could be a problem with browser/cookie persistence or server P3P file?  It seems more likely that is probably the culprit than the Form.FieldNames not showing up.

True, the data gets stored in session variables. But if the session scope gets lost, all of those session variables get re-defaulted in the next page load, via application.cfm. The action page is testing for something (fieldnames) in the form scope -- they are two different scopes, correct? If the session scope is gone, the action page should still evaluate what the form is passing, and send me on to the next page, which will then show null values for all of the form fields passed. Only if form.fieldnames does not exist will it redirect me back to the initial page -- and that's what's happening for some users.