DrByte:

I'm just suggesting to do it as a test to see what happens ... whether the problem follows. Just to rule some things out.

doing now...

What are your PHP settings for:

• register_globals
• post_max_size
• magic_quotes_gpx
• magic_quotes_runtime
• magic_quotes_sybase
• output_buffering
• zlib.output_compression
• variables_order

Is PHP running as an Apache module or as CGI ?

Do you have Zend Optimizer installed ? What version?

This is from php.ini:

• register_globals=off
• post_max_size=8M
• magic_quotes_gpc=off
• magic_quotes_runtime=off
• magic_quotes_sybase=off
• output_buffering=4096
• zlib.output_compression=off
• variables_order=GPCS

PHP5 is compiled and running as an apache module.

Zend Optimizer is installed. version: 220060519 (Zend Engine v2.2.0)

Back to the debugging idea ... instead of checking $_POST, try checking $HTTP_RAW_POST_DATA instead.
(ref: http://bugs.php.net/bug.php?id=32109 old php bug report)

Perhaps check $_REQUEST too ?
http://bugs.php.net/bug.php?id=31417

Here's a workaround someone proposed, assuming affirmative results for the test of the raw data:```
if (isset($GLOBALS['HTTP_RAW_POST_DATA']) && !count($_POST))
parse_str($GLOBALS['HTTP_RAW_POST_DATA'] , $_POST);

Better yet ... do you have mod_auth_sspi 1.0.4 compiled into your configuration ?
http://yellow5.us/journal/empty_post_requests_and_ie7/

This article discusses almost identical symptoms, and suggests that it happens only if you click your Submit within 15 seconds of a previous click. Would be interesting to know if that has any bearing for you.

(I doubt it for the carterellis site, since I see symptoms even without the 15-sec timer just on the catalog)

DrByte:

instead of checking $_POST, try checking $HTTP_RAW_POST_DATA instead.
(ref: http://bugs.php.net/bug.php?id=32109 old php bug report)

I think I've already tried it, but I'll try again.

Interesting...your code (the <pre> tag) yields nothing. I checked to see if it isset() and it is NOT.

(Notice: Undefined variable: HTTP_RAW_POST_DATA in /usr/home/jar/store/zencart/admin/configuration.php on line 28) after the isset code, denoting its not recognized...but thats obvious :P

I have mod_auth but not mod_auth_sspi installed.

(That link doesn't work for me btw, but 15 second rule doesn't apply)

Athenon:

(Notice: Undefined variable: HTTP_RAW_POST_DATA in /usr/home/jar/store/zencart/admin/configuration.php on line 28)I'm somewhat unsurprised ... I believe those were deprecated awhile back anyway. The PHP bug report is a little old.
I just tested it too, and get the same result on PHP 5.2.3.

DrByte:

Better yet ... do you have mod_auth_sspi 1.0.4 compiled into your configuration ?
http://yellow5.us/journal/empty_post_requests_and_ie7/

This article discusses almost identical symptoms, and suggests that it happens only if you click your Submit within 15 seconds of a previous click. Would be interesting to know if that has any bearing for you.

(I doubt it for the carterellis site, since I see symptoms even without the 15-sec timer just on the catalog)

The article contents:> Empty POST requests and IE7

I experienced a serious issue having to do with POST requests, and the only browser that seemed to be affected was IE7 RC.

The Symptom
After submitting form data as a POST request multiple times to the same page, my PHP test page would return an empty $_POST superglobal, meaning no data was received. Strangely, this only occurred if I submitted the form more than once within 15 seconds.

The first form submit always worked as expected, but any subsequent submit within the next 15 seconds came up empty. If I waited beyond the seemingly arbitrary 15-second limit and submitted the form, it again worked as expected.

Furthermore, I noticed that the issue only manifested itself on my machine, the test server. If I submitted a request using the same test script on the production server, IE7 worked flawlessly.

The Solution
I compared settings in my php.ini, .htaccess, and httpd.conf files, with no luck. I then decided to check the versions of everything, including PHP, Apache, and all installed modules and extensions. The test server had the latest versions of Apache, PHP, and most modules installed, while the production server was one or two minor revisions behind on each.

One of the loaded Apache modules I found with differing versions was mod_auth_sspi, which is conveniently hosted here. The test server used mod_auth_sspi 1.0.4, while the production server used 1.0.3. After downgrading to mod_auth_sspi 1.0.3, the annoying empty POST issue disappeared.

Final Words
If you're running Apache and using mod_auth_sspi 1.0.4, I strongly suggest writing a quick script to submit data as a POST, and testing it with IE7. If you notice any strange activity at all, consider rolling back to 1.0.3. It may save you a serious headache later on.

It's possible that this is an issue with IE7 RC. If so, it may be fixed in the final version

DrByte:

I'm somewhat unsurprised ... I believe those were deprecated awhile back anyway. The PHP bug report is a little old.
I just tested it too, and get the same result on PHP 5.2.3.

So what do we do? I REALLY need this to work for business, and no app is as satisfying as ZenCart :(

Athenon:

So what do we do? I REALLY need this to work for business, and no app is as satisfying as ZenCart :(

I feel your pain there ! And I share your conviction too !

I'm still digging ...

Two issues raised in this article:
http://bugs.php.net/bug.php?id=26004

• form enctype quirks
• suggested adding of a hidden form field of name="MAX_FILE_SIZE" value="50000000" inside the form

"If the size of post data is greater than post_max_size, the $_POST and
$_FILES superglobals are empty.
When reguesting a page with the POST method and the enctype is set to
"multipart/form-data", the $_POST suberglobal is left empty.

(Post requests without enctype="multipart/form-data" work fine.)
The problem though ...is that this particular page doesn't use the enctype. It uses the defaults.

I was going to suggest this:
line 197 says:$contents = array('form' => zen_draw_form('configuration', FILENAME_CONFIGURATION, 'gID=' . $_GET['gID'] . '&cID=' . $cInfo->configuration_id . '&action=save'));so try adding this on the next line:```
$contents[] = array('text' => zen_draw_hidden_field('MAX_FILE_SIZE', "50000000"));

Nope, same thing...I've tried it before a different way, but same result either way.

http://bugs.php.net/bug.php?id=22138

[9 Feb 2003 9:33am UTC] stchang at seed dot net dot tw
Hi!
I wrote a simple script to upload files through web sever. However, the
script work fine with apache 1.3. As upgrading to redhat 8.0. The script
can't upload files exceed 500k. It report "Request entity too large." I
tried to change post_max_size, upload_max_filesize. It still can't work.
Does someone can help me?

Thanks!
[9 Feb 2003 9:39am UTC] moriyoshi AT php.net
Please check if your httpd.conf has a LimitRequestBody directive to
limit the amount of incoming data.

[20 Feb 2003 8:12am UTC] sniper AT php.net
Configure PHP into httpd.conf as documented in
http://www.php.net/manual/en/install.apache2.php

#cat /usr/local/etc/apache/httpd.conf | grep LimitRequestBody

so...nope, not a LimitRequestBody directive
:(

As an aside note:

http://www.php.net/manual/en/language.variables.predefined.php
rick AT independence,netI
23-Jul-2001 06:13
It should be noted that $HTTP_RAW_POST_DATA only exists if the encoding type of the data is -not- the default of application/x-www.form-urlencoded, and so, to accessing raw post data from an HTTP form requires setting enctype= in your HTML.

i am still working on the ftp, so, i will be looking here to see if it was resolved, and if it ends up working fo rme, i will post back here too.

Just so nobody confused me with the FTP thing: I downloaded straight to the server, extracted it and moved it to where it needed to go. :P

As an aside note:

http://www.php.net/manual/en/language.variables.predefined.php
rick AT independence,netI
23-Jul-2001 06:13
It should be noted that $HTTP_RAW_POST_DATA only exists if the encoding type of the data is -not- the default of application/x-www.form-urlencoded, and so, to accessing raw post data from an HTTP form requires setting enctype= in your HTML.I just tested this concept, and it doesn't seem to make any difference:```
$contents = array('form' => zen_draw_form('configuration', FILENAME_CONFIGURATION, 'gID=' . $_GET['gID'] . '&cID=' . $cInfo->configuration_id . '&action=save', 'post', 'enctype="multipart/form-data"'));

Interesting aside: <http://www.htmlcodetutorial.com/forms/form_enctype.html>

So you are able to reproduce the error DrByte?

I did a print_r( $GLOBALS )...here's the results (warning: fairly long)

Array ( [GLOBALS] => Array RECURSION [_POST] => Array ( ) [HTTP_POST_VARS] => Array ( ) [_GET] => Array ( [gID] => 1 [cID] => 4 [action] => save ) [HTTP_GET_VARS] => Array ( [gID] => 1 [cID] => 4 [action] => save ) [_COOKIE] => Array ( [__utma] => 190618288.598261983.1183229530.1188109571.1188113018.38 [__utmz] => 190618288.1183229530.1.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none) [cookieid] => e2d497219bcd789ce19f835ceb3c20ee [__utmc]

Apache/1.3.37 Server at store.japanaradio.com Port 443

[SERVER_SOFTWARE] => Apache/1.3.37 (Unix) mod_perl/1.30 PHP/5.2.3 mod_ssl/2.8.28 OpenSSL/0.9.7e-p1 [SSL_CIPHER] => DHE-RSA-AES256-SHA [SSL_CIPHER_ALGKEYSIZE] => 256 [SSL_CIPHER_EXPORT] => false [SSL_CIPHER_USEKEYSIZE] => 256 [SSL_CLIENT_VERIFY] => NONE [SSL_PROTOCOL] => SSLv3 [SSL_SERVER_A_KEY] => rsaEncryption [SSL_SERVER_A_SIG] => sha1WithRSAEncryption [SSL_SERVER_I_DN] => /C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU=htt

Apache/1.3.37 Server at store.japanaradio.com Port 443

[SERVER_SOFTWARE] => Apache/1.3.37 (Unix) mod_perl/1.30 PHP/5.2.3 mod_ssl/2.8.28 OpenSSL/0.9.7e-p1 [SSL_CIPHER] => DHE-RSA-AES256-SHA [SSL_CIPHER_ALGKEYSIZE] => 256 [SSL_CIPHER_EXPORT] => false [SSL_CIPHER_USEKEYSIZE] => 256 [SSL_CLIENT_VERIFY] => NONE [SSL_PROTOCOL] => SSLv3 [SSL_SERVER_A_KEY] => rsaEncryption [SSL_SERVER_A_SIG] => sha1WithRSAEncryption [SSL_SERVER_I_DN] => /C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU=htt

[entry] => Array ( [autoType] => init_script [loadFile] => init_html_editor.php ) [classPath] => includes/classes/ [objectName] => messageStack [className] => messageStack [zco_notifier] => notifier Object ( [observers] => Array ( ) ) [baseDir] => includes/init_includes/ [request_type] => SSL [extra_datafiles_dir] => includes/extra_datafiles/ [dir] => Directory Object ( [path] => includes/extra_datafiles/ [handle] => Resource id #29 ) [file]

Athenon:

So you are able to reproduce the error DrByte?

No -- I've tried all kinds of things and cannot reproduce it.