Sporadic loss of FORM scope data

[Nick_UK]

try placing the submit button after the form fields. Basically the last thing on the page to load

[philh]

Say you have a field named "residence" at the end of your form. This function
prohibits submission until the field exists in the DOM:

function docudone() {
if (!document.forms(0).residence)
{alert('Please try your submission again');
return false};}

Put an onclick event handler in the Submit button to run this function.

HTH,

[MattRobertson]

How interesting. I have seen this form field disappearance bit off and on for
years myself. I know Paul said he couldn't find anything on it but I know
there have been threads on the subject over the years dating back to the
allaire.com forums. Never did like the search here.

Anyway I have a single user on an intranet right now who is experiencing this
to a significantly annoying degree. I've never been able to pin it down to a
single individual like this. I've also never had the diagnostic tools in place
like I do nowadays (its been awhile since I've seen this). I have found a
couple of things:

1. The entire form scope disappears. As in everything. Not even
form.fieldnames or the form.x and form.y of the submit button. However when
the submission arrives I write code that adds three form fields to the
submitted list (as in [cfset form.brokernumber=123]. These three fields make
up the entire contents of the form scope.

2. It doesn't always do it. However once it starts the problem -- on the
subject site, at least... no idea if posts work on other web sites -- can only
be cured via a browser close and re-open. This fixes the problem.

3. Some users have never seen it happen, ever.

4. An examination of the cgi scope reveals that cgi.request_method says this
is a GET(!!!!). So the form fields should be appended to the query string if
its a form GET, right? Wrongamundo. The query string is set as expected (it
already contains two parameters).

The tool I'm experiencing this on is GridMonger, which is something thats in
use literally tens of thousands of times daily. No reports of problems like
this.

The server its happening on is CF5.

I'm going to check to make sure GridMonger's form statement properly says
"post" in it (it had better or I'm an idiot) and see if I can otherwise figure
out what the hell is going on. The GET discovery is a new one for me. The
rest I've seen before.

This *has* to be the browser. CF is apparently not getting a properly
formatted submission back from the browser.

[ksmith]

I have just resolved a customer's issue who is having the undefined form field
issue. Lets start by stating the obvious - this error can be caused by lots of
different reasons. So, there is no 1 solution for everyone.

Here is a brief scenerio of the customer's issue. They found only some users
are having this problem. These users have it from any client PC they run from.
It only shows for iexplorer and not other browsers. Finally, it only occurs
as they hit a specific server. Form POSTs to other servers work fine for these
same users.

We covered all the basics mentioned in this and other threads. We cleared
cookies and cache. We confirmed cookies and javascript were enabled. We
tested straight html forms and cfml cfforms hitting a cfml action page. All
failed.

We then used the sniffer application included with CFMX
(\cfusionmx\runtime\bin\sniffer.exe.) We watched the posting of the forms and
the replies. Interestingly in this case the POSTs did contain the form data.

But the headers also included certificate information. The certificate itself
is over 4300 bytes. ColdFusion limits header size to 4k and truncates
additional information. That is the problem. The form fields are truncated by
the webserver connector before they get to CFMX! Luckily for users of CFMX 6.1
with updater 1, there is a hotfix. Here is the
[url]http://www.macromedia.com/go/tn_19352[/url]

Again this fix is specific to users of CFMX 6.x. You must upgrade CFMX 6.0
and CFMX 6.1 to CFMX 6.1 with its updater 1 installed. Then apply the hotfix
mentioned above. This specific problem should not exist for CFMX7 users. Also
CFMX 6.x users running the J2EE installation on JRun 4 with updater 4 or higher
should not have this issue.

[MattRobertson]

Ken,

If I'm reading you right, this would be an issue where a secure certificate is
in use in the transaction?

Doesn't help my specific circumstance but very valuable information
nonetheless. I don't think any of my 6.1 servers have that post-Updater 1
hotfix.

Thanks for the followup,

--Matt--
MSB Web Systems... [url]http://mysecretbase.com[/url]
It's a poor workman who blames his tools.
- Today's Fortune Cookie

[ksmith]

Matt,
You have it correct. Of course, the more general issue is anytime you have headers over 4k, this may occur.

[MattRobertson]

I'm not particularly savvy on browser communication with the server. Are
POSTed form vars carried via headers to the server? My form has a wysiwyg
textarea field which in turn ties in to a sql server ntext field. Could be a
lot of characters in there.

Independent of your answer above, am I to take this to mean CF 5 also has a 4k
header issue?

--Matt--
MSB Web Systems... [url]http://mysecretbase.com[/url]
Pay no attention to that man behind the curtains.
- Today's Fortune Cookie

[ksmith]

Yes they are carried in a header. Yes CF5 uses a 4k header buffer. I believe
that is because it was a W3C standard to limit headers to 4k. I do not know if
that was updated to accept larger headers or the standard is being ignored.

[plange]

I'm having this issue too - on Firefox only:

[url]http://www.macromedia.com/cfusion/webforums/forum/messageview.cfm?catid=3&threadid=1004811&highlight _key=y&keyword1=firefox[/url]

[simonr]

Has anyone tried [url]http://www.macromedia.com/go/238944b1[/url] hotix?

I'd have a go myself, but the client who reported it has gone quiet on the
matter, so it may be a different issue (e.g. something on their network).

[plange]

will try it tonight, but can't imagine the header restriction is it, since there's only one form field and 1 hidden field....

[plange]

Weird thing, though, same site, Firefox, different form, no error: [url]http://www.inspiredtype.com/contact/index.cfm?Fuseaction=contact&section=contact[/url]

and it has more form fields?

[plange]

Just had a report of same error if user is using Safari.

[Frost_Trunks]

Try checking your Output Caching in your server IIS Manager for the website in question. I had the exact same issue where my form.variablename would appear to vanish on form submission. My caching extension was set to all web page types (set as *), and because the coldfusion page was posting to itself, it would load the cached version instead of reloading it with the form variables. I removed the * extension and set it to only cache my asp.net pages and not anything else. After making this change, my form variables worked just fine in CF pages. Hope this helps!