Forms won't pass data properly

Works on another server

[Hester]

In transferring a website from one host to another I have had to rewrite a lot of pages. Luckily I was able to edit the php.ini configuration file to get most pages back up and running again, but two forms have me stumped.

The new server is Windows NT running IIS PHP 4.2.2 with register_globals OFF. The old server was Solaris running Apache PHP 4.2.1 with register_globals ON. So my forms used to pass variables using POST, then I referenced the variables by name. Now I am converting them using this code:

$text = "Company Name: ".$_POST['companyname']. (etc)

I'm adding several variables together so they can be sent via email.

The problem lies in the first page which seems to get stuck. If I type a single character into any of the form fields it works fine. But anything much longer and it just hangs. The browser saying it's opening the next page but it never does. Eventually the script times out.

It seems to happen in a way I can't nail down. Sometimes the form goes through, other times not. But I can guarantee it fails if you type in long entries like "mmmmmmmmmmmmmmmmm".

The mystery is made stranger by the fact that this problem only affects Internet Explorer (6). On Mozilla and Netscape 4, the form works! So now I'm thinking it's the IE6 cache - nope, cleared that. Then maybe the mime header? Or the HTML is wrong somehow but I have checked my code. (It's XHTML Transitional with <fieldset> tags.)

Here's a sample of the form code:

<form name="form1" method="post" action="email.php">
<fieldset>
<legend><nolayer>My Form</nolayer></legend>
<label for="companyname"><b>Company Name: </b><input type="text" size="50" name="companyname" /></label>

I have searched the PHP manual website but cannot find any answer. Besides register_globals, the two servers used share almost the same settings. Both use the default 8M for maximum post bytes. Is it the server or my code? Do I need to add something extra to the page? Or is it an IE6 bug?

[coopster]

A few things to try:

1. I ran into a similar situation awhile back regarding the register_globals directive. This post regarding register_globals [webmasterworld.com] should offer some insight.
   
2. I have seen IE cause issues in forms, not just PHP or Perl, but standard HTML forms as well. I had to clear history, cookies, etc. before the browser would function correctly. You may also want to tell your browser to automatically check for newer versions of stored pages (General tab, Temporary Internet Settings button).
   
3. You aren't closing your fieldset tag in the code you posted.

Sounds like you have a tough issue on your hands. If you want me to test anything, stickymail me the test url and I'll give it a shot.

[Hester]

Thanks, I'll try those options.

You aren't closing your fieldset tag in the code you posted.

It's just a snippet of the code.

[Hester]

I tried the options suggested but they did not work. Since the browser worked before on a different server, I can only conclude that there is something in the code or browser that doesn't like the new setup. What's odd is both browser and server are now Windows, so you'd have thought that would give the least problems.

[coopster]

I'm adding several variables together so they can be sent via email.

I'm making an assumption that you may be using the

mail() function

in your php script. Also, you seem to have narrowed down a possibility in your last post:

Since the browser worked before on a different server, I can only conclude that there is something in the code or browser that doesn't like the new setup.

...you've been scrutinizing the browser and script, but maybe it's time to analyze the server instead. This warning is right out of the mail() function Manual pages: [us4.php.net]

The Windows implementation of mail() differs in many ways from the Unix implementation. First, it doesn't use a local binary for composing messages but only operates on direct sockets which means a MTA is needed listening on a network socket (which can either on the localhost or a remote machine). Second, the custom headers like From:, Cc:, Bcc: and Date: are not interpreted by the MTA in the first place, but are parsed by PHP. PHP < 4.3 only supported the Cc: header element (and was case-sensitive). PHP >= 4.3 supports all the mentioned header elements and is no longer case-sensitive.

[Hester]

Ah. Yes, I am using mail() as in the following code:

mail("c.a.hester@blahblahblah", "Registration", $text2);

However, the emails CAN go through if I use single characters in the form fields. Perhaps it's a buffer problem? Also the page before the mail() code is the one sticking, before a second page with the above code in it.

I've tried using PHP SELF to use mail() on the same page but still it sticks.

[Hester]

Please help. I couldn't get the form to work so I scrapped the page and did it another way. But now I have just set up a forum only to find the IE6 problem is there again! I cannot post new messages (after registering using Mozilla). The browser just hangs, with the 'loading' bar incrementing at the bottom.

If I can't solve this one, the forum is useless. I should have remembered about the problem in IE but I use Mozilla mostly now, only checking IE now and then.

I can edit the PHP.ini file if that helps. Otherwise I can ask the site admin guy to tweak the settings. Only I am in the dark. What could possibly be wrong?

This link suggests a character limit problem?

[faqts.com ]

Now I must play detective and search the net for clues!

[Hester]

If I use GET, a form using <textarea> only allows 235 chars to go through in IE6! If I use <input> I can get 326 through before it stalls. So I changed the form to use POST and now it lets 1706 chars through! Any more and the browser doesn't do anything. (Not even a loading progress bar.)

Is there any reason not to use POST instead of GET? Or is there a way to boost the 'buffer' used by GET to allow more characters to be passed from a form?

[coopster]

A couple of links that have some troubleshooting information. Note, some of the problems being discussed are file uploads, but some of the directives hold true for any type of form POST methods:
[webmasterworld.com...]
[webmasterworld.com...]