php-general Digest 25 Apr 2013 01:46:42 -0000 Issue 8208

[php-general-digest-help]

php-general Digest 25 Apr 2013 01:46:42 -0000 Issue 8208

Topics (messages 320975 through 320985):

IE 10 bug?
        320975 by: Jim Giner

Updated PHP breaks processing-intense Procedure
        320976 by: Ken Kixmoeller
        320977 by: David OBrien
        320978 by: Ken Kixmoeller
        320979 by: David OBrien
        320980 by: Ken Kixmoeller
        320981 by: Jim Lucas
        320982 by: Ken Kixmoeller
        320983 by: Jim Lucas
        320984 by: Ken Kixmoeller

Re: Load testing an app
        320985 by: tamouse mailing lists

Administrivia:

To subscribe to the digest, e-mail:
        php-general-digest-subscr...@lists.php.net

To unsubscribe from the digest, e-mail:
        php-general-digest-unsubscr...@lists.php.net

To post to the list, e-mail:
        php-gene...@lists.php.net


----------------------------------------------------------------------

--- Begin Message ---

I know - it sounds OT, but listen.

I have a form that has a "sign in " button which attempts to sent the user to a form in a password-protected folder. In order to get there the user must provide credentials. Once there the receiving script simply sets a session var and does a header() back to the calling script, where because of the session var that was set, a new group of buttons are visible for the user to click.

Well, M$ did an update last week on me and now IE10 is acting differently in the above scenario. Instead of my screen showing me back on my original menu screen it shows some other application window, probably the next one in z-order sequence.(?) It looks like my app crashed or something since my IE is now behind the other appls sometimes.

Has anyone else seen this, and if so, how does one counter it?

--- End Message ---

--- Begin Message ---

Hey - --

I have a huge screen -- to make it simple for the user, it does 100s of
calls to MySQL and has 1,000s (literally) of POST variables.

We have done extensive research and see that upgrading from php 5.1.6-27 to
5.1.6-39 is the thing that caused it to break. All other issues (Apache,
PHP and MySQL configuration and Versions) have been methodically ruled out.


Anybody experience this? Heard of it? Suggest a repair (other than changing
my screen)?

*** Please don't tell me to redesign the screen -- this may come, but now
is an urgent situation.***

Worked fine in prior versions for the last 3 years.

Thanks,

Ken

--- End Message ---

--- Begin Message ---

On Wed, Apr 24, 2013 at 5:09 PM, Ken Kixmoeller <phph...@comcast.net> wrote:

> Hey - --
>
> I have a huge screen -- to make it simple for the user, it does 100s of
> calls to MySQL and has 1,000s (literally) of POST variables.
>
> We have done extensive research and see that upgrading from php 5.1.6-27 to
> 5.1.6-39 is the thing that caused it to break. All other issues (Apache,
> PHP and MySQL configuration and Versions) have been methodically ruled out.
>
>
> Anybody experience this? Heard of it? Suggest a repair (other than changing
> my screen)?
>
> *** Please don't tell me to redesign the screen -- this may come, but now
> is an urgent situation.***
>
> Worked fine in prior versions for the last 3 years.
>
> Thanks,
>
> Ken
>

Looks like they fixed the bug that allowed that to work...
php-common-5.1.6-32.el5.x86_64<http://linuxsoft.cern.ch/cern/slc5X/x86_64/yum/updates/php-common-5.1.6-32.el5.x86_64.rpm>
 [153 KiB]*Changelog* by Joe Orton (2012-02-02): - add security fix for
CVE-2012-0830 (#786756)
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0830

--- End Message ---

--- Begin Message ---

>From the link: "The php_register_variable_ex function in php_variables.c in
PHP 5.3.9 allows remote attackers to execute arbitrary code via a request
containing a large number of variables, related to improper handling of
array variables. NOTE: this vulnerability exists because of an incorrect
fix"

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

I wondered if it was memory handling, but what is it (I wonder out loud)
that could be "improper" about my array handling. No error messages are
thrown.

Ken


On Wed, Apr 24, 2013 at 4:14 PM, David OBrien <dgobr...@gmail.com> wrote:

> On Wed, Apr 24, 2013 at 5:09 PM, Ken Kixmoeller <phph...@comcast.net>wrote:
>
>> Hey - --
>>
>> I have a huge screen -- to make it simple for the user, it does 100s of
>> calls to MySQL and has 1,000s (literally) of POST variables.
>>
>> We have done extensive research and see that upgrading from php 5.1.6-27
>> to
>> 5.1.6-39 is the thing that caused it to break. All other issues (Apache,
>> PHP and MySQL configuration and Versions) have been methodically ruled
>> out.
>>
>>
>> Anybody experience this? Heard of it? Suggest a repair (other than
>> changing
>> my screen)?
>>
>> *** Please don't tell me to redesign the screen -- this may come, but now
>> is an urgent situation.***
>>
>> Worked fine in prior versions for the last 3 years.
>>
>> Thanks,
>>
>> Ken
>>
>
> Looks like they fixed the bug that allowed that to work...
> php-common-5.1.6-32.el5.x86_64<http://linuxsoft.cern.ch/cern/slc5X/x86_64/yum/updates/php-common-5.1.6-32.el5.x86_64.rpm>
>  [153 KiB] *Changelog* by Joe Orton (2012-02-02): - add security fix for
> CVE-2012-0830 (#786756)
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0830
>
>
>

--- End Message ---

--- Begin Message ---

On Wed, Apr 24, 2013 at 5:14 PM, David OBrien <dgobr...@gmail.com> wrote:

> On Wed, Apr 24, 2013 at 5:09 PM, Ken Kixmoeller <phph...@comcast.net>wrote:
>
>> Hey - --
>>
>> I have a huge screen -- to make it simple for the user, it does 100s of
>> calls to MySQL and has 1,000s (literally) of POST variables.
>>
>> We have done extensive research and see that upgrading from php 5.1.6-27
>> to
>> 5.1.6-39 is the thing that caused it to break. All other issues (Apache,
>> PHP and MySQL configuration and Versions) have been methodically ruled
>> out.
>>
>>
>> Anybody experience this? Heard of it? Suggest a repair (other than
>> changing
>> my screen)?
>>
>> *** Please don't tell me to redesign the screen -- this may come, but now
>> is an urgent situation.***
>>
>> Worked fine in prior versions for the last 3 years.
>>
>> Thanks,
>>
>> Ken
>>
>
> Looks like they fixed the bug that allowed that to work...
> php-common-5.1.6-32.el5.x86_64<http://linuxsoft.cern.ch/cern/slc5X/x86_64/yum/updates/php-common-5.1.6-32.el5.x86_64.rpm>
>  [153 KiB] *Changelog* by Joe Orton (2012-02-02): - add security fix for
> CVE-2012-0830 (#786756)
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0830
>
>
>

*I looked around google some more and found there is a hard limit of 1000
post variables in 5.1.6*

After weeks of using it, a problem was reported about just one function of
the app that would sometimes return a blank screen. It took me hours of
debugging (read: echo) to figure out what's going on, digging through some
old PHP code (fun!): It appeared that only 1000 post variables arrived on
the server. (Well, 1006 actually, but 2 were added by PHP, and that sounded
like a PHP-style limitation of 1000.) A quick google lookup revealed that
PHP introduced a new feature where it would limit the number of post
variables. For safety reasons.

The variable is called "max_input_vars" with a default of 1000. PHP states
that this feature was introduced in 5.3.9, but I'm running 5.1.6 and the
limit is enforced.

Because the server is for production, it was running with on-screen
warnings turned off. PHP says that it "prints a warning and cuts". For me,
that's a real WTF. A post request should be processed as all-or-nothing.
It should instead refuse the request completely. But for a technology named
"personal home page" the priorities are different.

--- End Message ---

--- Begin Message ---

Thanks so much. Yes, we found that because PHP threw an error that said
that explicitly. A bit of research led us to add a line to php.ini to set
the "max_input_vars" to a higher level.

At first, that appeared to fix it (on the development machine). The
appearance is wrong; it is still broken. No errors are being thrown. We are
baffled.

Ken


On Wed, Apr 24, 2013 at 4:23 PM, David OBrien <dgobr...@gmail.com> wrote:

> On Wed, Apr 24, 2013 at 5:14 PM, David OBrien <dgobr...@gmail.com> wrote:
>
>> On Wed, Apr 24, 2013 at 5:09 PM, Ken Kixmoeller <phph...@comcast.net>wrote:
>>
>>> Hey - --
>>>
>>> I have a huge screen -- to make it simple for the user, it does 100s of
>>> calls to MySQL and has 1,000s (literally) of POST variables.
>>>
>>> We have done extensive research and see that upgrading from php 5.1.6-27
>>> to
>>> 5.1.6-39 is the thing that caused it to break. All other issues (Apache,
>>> PHP and MySQL configuration and Versions) have been methodically ruled
>>> out.
>>>
>>>
>>> Anybody experience this? Heard of it? Suggest a repair (other than
>>> changing
>>> my screen)?
>>>
>>> *** Please don't tell me to redesign the screen -- this may come, but now
>>> is an urgent situation.***
>>>
>>> Worked fine in prior versions for the last 3 years.
>>>
>>> Thanks,
>>>
>>> Ken
>>>
>>
>> Looks like they fixed the bug that allowed that to work...
>> php-common-5.1.6-32.el5.x86_64<http://linuxsoft.cern.ch/cern/slc5X/x86_64/yum/updates/php-common-5.1.6-32.el5.x86_64.rpm>
>>  [153 KiB] *Changelog* by Joe Orton (2012-02-02): - add security fix for
>> CVE-2012-0830 (#786756)
>> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0830
>>
>>
>>
>
> *I looked around google some more and found there is a hard limit of 1000
> post variables in 5.1.6*
>
> After weeks of using it, a problem was reported about just one function of
> the app that would sometimes return a blank screen. It took me hours of
> debugging (read: echo) to figure out what's going on, digging through some
> old PHP code (fun!): It appeared that only 1000 post variables arrived on
> the server. (Well, 1006 actually, but 2 were added by PHP, and that sounded
> like a PHP-style limitation of 1000.) A quick google lookup revealed that
> PHP introduced a new feature where it would limit the number of post
> variables. For safety reasons.
>
> The variable is called "max_input_vars" with a default of 1000. PHP states
> that this feature was introduced in 5.3.9, but I'm running 5.1.6 and the
> limit is enforced.
>
> Because the server is for production, it was running with on-screen
> warnings turned off. PHP says that it "prints a warning and cuts". For me,
> that's a real WTF. A post request should be processed as all-or-nothing.
> It should instead refuse the request completely. But for a technology
> named "personal home page" the priorities are different.
>
>
>

--- End Message ---

--- Begin Message ---

On 04/24/2013 02:40 PM, Ken Kixmoeller wrote:

Thanks so much. Yes, we found that because PHP threw an error that said
that explicitly. A bit of research led us to add a line to php.ini to set
the "max_input_vars" to a higher level.

At first, that appeared to fix it (on the development machine). The
appearance is wrong; it is still broken. No errors are being thrown. We are
baffled.

Ken

If you have the Suhosin patch installed, it also introduces other limits to GET and POST variable counts within PHP.

--
Jim Lucas

http://www.cmsws.com/
http://www.cmsws.com/examples/

--- End Message ---

--- Begin Message ---

Thanks, Jim ---

Is this different from the "max_input_vars" discussion above? (from David
OBrien)

Ken


On Wed, Apr 24, 2013 at 5:06 PM, Jim Lucas <li...@cmsws.com> wrote:

> On 04/24/2013 02:40 PM, Ken Kixmoeller wrote:
>
>> Thanks so much. Yes, we found that because PHP threw an error that said
>> that explicitly. A bit of research led us to add a line to php.ini to set
>> the "max_input_vars" to a higher level.
>>
>> At first, that appeared to fix it (on the development machine). The
>> appearance is wrong; it is still broken. No errors are being thrown. We
>> are
>> baffled.
>>
>> Ken
>>
>
> If you have the Suhosin patch installed, it also introduces other limits
> to GET and POST variable counts within PHP.
>
> --
> Jim Lucas
>
> http://www.cmsws.com/
> http://www.cmsws.com/examples/
>

--- End Message ---

--- Begin Message ---

On 04/24/2013 03:24 PM, Ken Kixmoeller wrote:

Thanks, Jim ---

Is this different from the "max_input_vars" discussion above? (from David
OBrien)

yes.  For example...

php.ini:[suhosin]
php.ini:;suhosin.log.syslog =
php.ini:;suhosin.log.syslog.facility =
php.ini:;suhosin.log.syslog.priority =
php.ini:;suhosin.log.sapi =
php.ini:;suhosin.log.script =
php.ini:;suhosin.log.phpscript = 0
php.ini:;suhosin.log.script.name =
php.ini:; variables registered in the current scope: SUHOSIN_ERRORCLASS and

php.ini:; SUHOSIN_ERROR. The first one is the alert class and the second variable is

php.ini:;suhosin.log.phpscript.name =
php.ini:;suhosin.log.phpscript.is_safe = Off
php.ini:;suhosin.log.use-x-forwarded-for = Off
php.ini:;suhosin.executor.max_depth = 0
php.ini:;suhosin.executor.include.max_traversal = 0
php.ini:;suhosin.executor.include.whitelist =
php.ini:;suhosin.executor.include.blacklist =
php.ini:;suhosin.executor.func.whitelist =
php.ini:;suhosin.executor.func.blacklist =
php.ini:;suhosin.executor.eval.whitelist =
php.ini:;suhosin.executor.eval.blacklist =
php.ini:;suhosin.executor.disable_eval = Off
php.ini:;suhosin.executor.disable_emodifier = Off

php.ini:; by default in Suhosin >= 0.9.6. Allowing symlink() while open_basedir is used

php.ini:;suhosin.executor.allow_symlink = Off

php.ini:; If you fear that Suhosin breaks your application, you can activate Suhosin's php.ini:; simulation mode with this flag. When Suhosin runs in simulation mode,

php.ini:;suhosin.simulation = Off

php.ini:; first. It always uses resource slot 0. If Suhosin got this slot assigned APC php.ini:; will overwrite the information Suhosin stores in this slot. When this flag is php.ini:; set Suhosin will request 2 Slots and use the second one. This allows working

php.ini:;suhosin.apc_bug_workaround = Off
php.ini:;suhosin.sql.bailout_on_error = Off
php.ini:;suhosin.sql.user_prefix =
php.ini:;suhosin.sql.user_postfix =
php.ini:;suhosin.multiheader = Off
php.ini:suhosin.mail.protect = 1

php.ini:; memory_limit to whatever value they want. Suhosin changes this fact and php.ini:; that Suhosin will disallows scripts setting the memory_limit to a value above

php.ini:;suhosin.memory_limit = 0
php.ini:suhosin.session.encrypt = Off
php.ini:;suhosin.session.cryptkey =
php.ini:;suhosin.session.cryptua = On
php.ini:;suhosin.session.cryptdocroot = On
php.ini:;suhosin.session.cryptraddr = 0

php.ini:; session. The difference to suhosin.session.cryptaddr is, that the IP is not

php.ini:;suhosin.session.checkraddr = 0
php.ini:;suhosin.cookie.encrypt = 0
php.ini:;suhosin.cookie.cryptkey =
php.ini:;suhosin.cookie.cryptua = On
php.ini:;suhosin.cookie.cryptdocroot = On
php.ini:;suhosin.cookie.cryptraddr = 0

php.ini:; cookie. The difference to suhosin.cookie.cryptaddr is, that the IP is not

php.ini:;suhosin.cookie.checkraddr = 0
php.ini:;suhosin.cookie.cryptlist =
php.ini:;suhosin.cookie.plainlist =
php.ini:; Defines the reaction of Suhosin on a filter violation.
php.ini:;suhosin.filter.action =
php.ini:;suhosin.cookie.max_array_depth = 50
php.ini:;suhosin.cookie.max_array_index_length = 64
php.ini:;suhosin.cookie.max_name_length = 64
php.ini:;suhosin.cookie.max_totalname_length = 256
php.ini:;suhosin.cookie.max_value_length = 10000
php.ini:;suhosin.cookie.max_vars = 100
php.ini:;suhosin.cookie.disallow_nul = 1
php.ini:;suhosin.get.max_array_depth = 50
php.ini:;suhosin.get.max_array_index_length = 64
php.ini:;suhosin.get.max_name_length = 64
php.ini:;suhosin.get.max_totalname_length = 256
php.ini:;suhosin.get.max_value_length = 512
php.ini:;suhosin.get.max_vars = 100
php.ini:;suhosin.get.disallow_nul = 1
php.ini:;suhosin.post.max_array_depth = 50
php.ini:;suhosin.post.max_array_index_length = 64
php.ini:;suhosin.post.max_name_length = 64
php.ini:;suhosin.post.max_totalname_length = 256
php.ini:suhosin.post.max_value_length = 2048000
php.ini:suhosin.post.max_vars = 500
php.ini:;suhosin.post.disallow_nul = 1
php.ini:;suhosin.request.max_array_depth = 50
php.ini:;suhosin.request.max_array_index_length = 64
php.ini:;suhosin.request.max_totalname_length = 256
php.ini:suhosin.request.max_value_length = 2048000
php.ini:;suhosin.request.max_vars = 200
php.ini:;suhosin.request.max_varname_length = 64
php.ini:;suhosin.request.disallow_nul = 1
php.ini:;suhosin.upload.max_uploads = 25
php.ini:;suhosin.upload.disallow_elf = 1
php.ini:;suhosin.upload.disallow_binary = 0
php.ini:;suhosin.upload.remove_binary = 0
php.ini:;suhosin.upload.verification_script =
php.ini:;suhosin.session.max_id_length = 128

php.ini:; Undocumented: Controls if suhosin coredumps when the optional suhosin patch

php.ini:;suhosin.coredump = Off
php.ini:;suhosin.protectkey = 1
php.ini:; Controls if suhosin loads in stealth mode when it is not the only
php.ini:;suhosin.stealth = 1
php.ini:; Controls if suhosin's ini directives are changeable per directory
php.ini:;suhosin.perdir = "0"

Ken


On Wed, Apr 24, 2013 at 5:06 PM, Jim Lucas <li...@cmsws.com> wrote:

On 04/24/2013 02:40 PM, Ken Kixmoeller wrote:

Thanks so much. Yes, we found that because PHP threw an error that said
that explicitly. A bit of research led us to add a line to php.ini to set
the "max_input_vars" to a higher level.

At first, that appeared to fix it (on the development machine). The
appearance is wrong; it is still broken. No errors are being thrown. We
are
baffled.

Ken

If you have the Suhosin patch installed, it also introduces other limits
to GET and POST variable counts within PHP.

--
Jim Lucas

http://www.cmsws.com/
http://www.cmsws.com/examples/

--
Jim Lucas

http://www.cmsws.com/
http://www.cmsws.com/examples/

--- End Message ---

--- Begin Message ---

Thank you very much, Jim ---


On Wed, Apr 24, 2013 at 5:34 PM, Jim Lucas <li...@cmsws.com> wrote:

> On 04/24/2013 03:24 PM, Ken Kixmoeller wrote:
>
>> Thanks, Jim ---
>>
>> Is this different from the "max_input_vars" discussion above? (from David
>> OBrien)
>>
>
> yes.  For example...
>
> php.ini:[suhosin]
> php.ini:;suhosin.log.syslog =
> php.ini:;suhosin.log.syslog.**facility =
> php.ini:;suhosin.log.syslog.**priority =
> php.ini:;suhosin.log.sapi =
> php.ini:;suhosin.log.script =
> php.ini:;suhosin.log.phpscript = 0
> php.ini:;suhosin.log.script.**name <http://suhosin.log.script.name> =
> php.ini:; variables registered in the current scope: SUHOSIN_ERRORCLASS and
> php.ini:; SUHOSIN_ERROR. The first one is the alert class and the second
> variable is
> php.ini:;suhosin.log.**phpscript.name <http://suhosin.log.phpscript.name>=
> php.ini:;suhosin.log.**phpscript.is_safe = Off
> php.ini:;suhosin.log.use-x-**forwarded-for = Off
> php.ini:;suhosin.executor.max_**depth = 0
> php.ini:;suhosin.executor.**include.max_traversal = 0
> php.ini:;suhosin.executor.**include.whitelist =
> php.ini:;suhosin.executor.**include.blacklist =
> php.ini:;suhosin.executor.**func.whitelist =
> php.ini:;suhosin.executor.**func.blacklist =
> php.ini:;suhosin.executor.**eval.whitelist =
> php.ini:;suhosin.executor.**eval.blacklist =
> php.ini:;suhosin.executor.**disable_eval = Off
> php.ini:;suhosin.executor.**disable_emodifier = Off
> php.ini:; by default in Suhosin >= 0.9.6. Allowing symlink() while
> open_basedir is used
> php.ini:;suhosin.executor.**allow_symlink = Off
> php.ini:; If you fear that Suhosin breaks your application, you can
> activate Suhosin's
> php.ini:; simulation mode with this flag. When Suhosin runs in simulation
> mode,
> php.ini:;suhosin.simulation = Off
> php.ini:; first. It always uses resource slot 0. If Suhosin got this slot
> assigned APC
> php.ini:; will overwrite the information Suhosin stores in this slot. When
> this flag is
> php.ini:; set Suhosin will request 2 Slots and use the second one. This
> allows working
> php.ini:;suhosin.apc_bug_**workaround = Off
> php.ini:;suhosin.sql.bailout_**on_error = Off
> php.ini:;suhosin.sql.user_**prefix =
> php.ini:;suhosin.sql.user_**postfix =
> php.ini:;suhosin.multiheader = Off
> php.ini:suhosin.mail.protect = 1
> php.ini:; memory_limit to whatever value they want. Suhosin changes this
> fact and
> php.ini:; that Suhosin will disallows scripts setting the memory_limit to
> a value above
> php.ini:;suhosin.memory_limit = 0
> php.ini:suhosin.session.**encrypt = Off
> php.ini:;suhosin.session.**cryptkey =
> php.ini:;suhosin.session.**cryptua = On
> php.ini:;suhosin.session.**cryptdocroot = On
> php.ini:;suhosin.session.**cryptraddr = 0
> php.ini:; session. The difference to suhosin.session.cryptaddr is, that
> the IP is not
> php.ini:;suhosin.session.**checkraddr = 0
> php.ini:;suhosin.cookie.**encrypt = 0
> php.ini:;suhosin.cookie.**cryptkey =
> php.ini:;suhosin.cookie.**cryptua = On
> php.ini:;suhosin.cookie.**cryptdocroot = On
> php.ini:;suhosin.cookie.**cryptraddr = 0
> php.ini:; cookie. The difference to suhosin.cookie.cryptaddr is, that the
> IP is not
> php.ini:;suhosin.cookie.**checkraddr = 0
> php.ini:;suhosin.cookie.**cryptlist =
> php.ini:;suhosin.cookie.**plainlist =
> php.ini:; Defines the reaction of Suhosin on a filter violation.
> php.ini:;suhosin.filter.action =
> php.ini:;suhosin.cookie.max_**array_depth = 50
> php.ini:;suhosin.cookie.max_**array_index_length = 64
> php.ini:;suhosin.cookie.max_**name_length = 64
> php.ini:;suhosin.cookie.max_**totalname_length = 256
> php.ini:;suhosin.cookie.max_**value_length = 10000
> php.ini:;suhosin.cookie.max_**vars = 100
> php.ini:;suhosin.cookie.**disallow_nul = 1
> php.ini:;suhosin.get.max_**array_depth = 50
> php.ini:;suhosin.get.max_**array_index_length = 64
> php.ini:;suhosin.get.max_name_**length = 64
> php.ini:;suhosin.get.max_**totalname_length = 256
> php.ini:;suhosin.get.max_**value_length = 512
> php.ini:;suhosin.get.max_vars = 100
> php.ini:;suhosin.get.disallow_**nul = 1
> php.ini:;suhosin.post.max_**array_depth = 50
> php.ini:;suhosin.post.max_**array_index_length = 64
> php.ini:;suhosin.post.max_**name_length = 64
> php.ini:;suhosin.post.max_**totalname_length = 256
> php.ini:suhosin.post.max_**value_length = 2048000
> php.ini:suhosin.post.max_vars = 500
> php.ini:;suhosin.post.**disallow_nul = 1
> php.ini:;suhosin.request.max_**array_depth = 50
> php.ini:;suhosin.request.max_**array_index_length = 64
> php.ini:;suhosin.request.max_**totalname_length = 256
> php.ini:suhosin.request.max_**value_length = 2048000
> php.ini:;suhosin.request.max_**vars = 200
> php.ini:;suhosin.request.max_**varname_length = 64
> php.ini:;suhosin.request.**disallow_nul = 1
> php.ini:;suhosin.upload.max_**uploads = 25
> php.ini:;suhosin.upload.**disallow_elf = 1
> php.ini:;suhosin.upload.**disallow_binary = 0
> php.ini:;suhosin.upload.**remove_binary = 0
> php.ini:;suhosin.upload.**verification_script =
> php.ini:;suhosin.session.max_**id_length = 128
> php.ini:; Undocumented: Controls if suhosin coredumps when the optional
> suhosin patch
> php.ini:;suhosin.coredump = Off
> php.ini:;suhosin.protectkey = 1
> php.ini:; Controls if suhosin loads in stealth mode when it is not the only
> php.ini:;suhosin.stealth = 1
> php.ini:; Controls if suhosin's ini directives are changeable per directory
> php.ini:;suhosin.perdir = "0"
>
>
>
>
>> Ken
>>
>>
>> On Wed, Apr 24, 2013 at 5:06 PM, Jim Lucas <li...@cmsws.com> wrote:
>>
>>  On 04/24/2013 02:40 PM, Ken Kixmoeller wrote:
>>>
>>>  Thanks so much. Yes, we found that because PHP threw an error that said
>>>> that explicitly. A bit of research led us to add a line to php.ini to
>>>> set
>>>> the "max_input_vars" to a higher level.
>>>>
>>>> At first, that appeared to fix it (on the development machine). The
>>>> appearance is wrong; it is still broken. No errors are being thrown. We
>>>> are
>>>> baffled.
>>>>
>>>> Ken
>>>>
>>>>
>>> If you have the Suhosin patch installed, it also introduces other limits
>>> to GET and POST variable counts within PHP.
>>>
>>> --
>>> Jim Lucas
>>>
>>> http://www.cmsws.com/
>>> http://www.cmsws.com/examples/
>>>
>>>
>>
>
> --
> Jim Lucas
>
> http://www.cmsws.com/
> http://www.cmsws.com/examples/
>

--- End Message ---

--- Begin Message ---

On Tue, Apr 23, 2013 at 8:04 AM, Andrew Ballard <aball...@gmail.com> wrote:
> On Tue, Apr 23, 2013 at 2:29 AM, Adam Richardson <simples...@gmail.com> wrote:
>> On Mon, Apr 22, 2013 at 10:41 PM, Andrew Ballard <aball...@gmail.com> wrote:
>>> The other developer in our office spent some time profiling the site with
>>> xdebug and found that an exec() call to netsh used on a couple pages seems
>>> to take 2-4 seconds to complete. Unfortunately, those exec() calls are the
>>> one function that we cannot test in our development environment.

I'm wondering if it would be possible to carve out the part doing the
netsh calls so they're not part of your web application's stack, and
make them an asynchronous part?

--- End Message ---