We are using CF8 on W2003.We have a form being used on our intranet.User submits form.Page specified in the form's action attribute fails, because the form variables are empty.If we dump the FORM, we see the structure is empty.More details:In IE, it fails when the URL uses a 'typical' host name like myhost.mydomain.mysuffix (e.g. fubar.xyz.pdq./somefile.cfm)In IE, it succeeds when using just the common name (fubar/somefile.cfm), or the host name that includes our Active Directory domain (fubar.adn.xyz.pdq/somefile.cfm)We are using application.cfm.The same files work on our development serverHappens only in IE. Firefox behaves properly, regardless of how the host is specified.Even more puzzling is that our existing production app worked up until a few days ago. And our inspections have shown no changes to either our CF code of the CF server settings.

zizzybaloobah

Participant

Question

Empty structure when form is submitted?

Forum|Forum|15 years ago
June 28, 2010
3 replies
962 views

We are using CF8 on W2003.

We have a form being used on our intranet.

User submits form.
Page specified in the form's action attribute fails, because the form variables are empty.
If we dump the FORM, we see the structure is empty.

More details:

In IE, it fails when the URL uses a 'typical' host name like myhost.mydomain.mysuffix (e.g. fubar.xyz.pdq./somefile.cfm)
In IE, it succeeds when using just the common name (fubar/somefile.cfm), or the host name that includes our Active Directory domain (fubar.adn.xyz.pdq/somefile.cfm)
We are using application.cfm.
The same files work on our development server

Happens only in IE. Firefox behaves properly, regardless of how the host is specified.

Even more puzzling is that our existing production app worked up until a few days ago. And our inspections have shown no changes to either our CF code of the CF server settings.

This topic has been closed for replies.

zizzybaloobahAuthor

Participant

I figured out at least one of possible two problems we're having.

Our incompetent team leader recently mangled our IIS settings - the CFM file with the form used NTLM access, while the CFM receiving the POSTed data allowed anonymous access. IE doesn't like posting data from an authenticated page to one that is isn't. When I changed the receiving CFM file to disable anonymous access, we were back in business.

The other problem I'm checking into is if our proxy is also causing problems. Apparently if clients are using http 1.1 (in which content_length is optional), while the proxy is running http 1.0 (content_length is required), it can cause problems because the proxy sets the content_length to 0 when content_length hasn't been specified.

Thanks all for the suggestions. I ended up using a utitlity called IE HTTPAnalyzer to check and compare what was happening when the form was posted.

A

Adam Cameron.

Inspiring

Sounds not identical but somewhat reminiscent of an issue I was having: http://forums.adobe.com/message/2760140

I did not get to the bottom of it.

--

Adam

zizzybaloobahAuthor

Participant

Adam,

Your experience does indeed match what is happening to us. Our particular app has worked for months without incident, and everything is reproduced exactly in our development envrionment and we can't get this to happen.

If I change the form's action to point to a different CFM page that lives elsewhere (it uses a different application.cfc or has no application.cfc) then we get the form variables as expected.

If I copy a basic, self-submitting form (that works elsewhere) into the problem directory, nothing shows up in the form variables.

I'm tempted to suspect Application.cfc, but the problem is this only happens in Internet Explorer 7 (on Win XP, all patches and SPs installed). We experience no issues whatsoever when using Firefox.

A

Adam Cameron.

Inspiring

Hmmm. I experienced it on Firefox and Chrome... I can't recall whether I tested on IE as I don't use it very often (only to test IE quirks).

Also, I experienced it in two different directories, and indeed on two different CF instances (CF801 & CF9)!

This lead me to think it was something cocked-up on my machine, however as I could see the form fields being passed correctly when using an HTTP packet sniffer, I became completely bamboozled as to WTF.

--

Adam

ilssac

Inspiring

Any chance the data is in the URL (i.e. the GET) scope?

If the form tag in the HTML has a 'method="get"' the data is not going to be in the FORM scope it is going to be in the URL scope.

A slightly more insidous way this can happen is through a redirect. Sometimes if browser makes a request of urlA that goes to a web server that is configured to redirect to urlB. When the redirect is done the post data is turned into get data in the request.

If not, we will have to dig deeper.

zizzybaloobahAuthor

Participant

I knew I left something out of my description. This form is using POST, not GET. We have been considering that redirections might be the culprit, but it doesn't appear that is case. I'm not sure how to verify whether or not that is indeed true.

ilssac

Inspiring

The quikest and simpliest test I can imagine is to dump the URL scope along with the FORM scope to see what is what.

The more complete solution would be to examin the network requests either at the client end, the server end and|or somewhere in between. Look at the actual reqeuest packets and see what data, if any is actually being sent and what type it is.

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded