<?xml version="1.0"?>
<rss version="2.0">
  <channel>
    <title>PHPDeveloper.org</title>
    <link>http://www.phpdeveloper.org</link>
    <description>Up-to-the Minute PHP News, views and community</description>
    <language>en-us</language>
    <pubDate>Tue, 18 Jun 2013 00:48:30 -0500</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[Kevin Schroeder: Setting max_input_time (with data!)]]></title>
      <guid>http://www.phpdeveloper.org/news/19023</guid>
      <link>http://www.phpdeveloper.org/news/19023</link>
      <description><![CDATA[<p>
<i>Kevin Schroeder</i> has a new post to his site today wondering about the "max_input_time" setting for PHP and <a href="http://www.eschrade.com/page/setting-max_input_time-with-data/">why some recommend it being a large number</a> despite the (usually) fast time PHP has accepting input.
</p>
<blockquote>
<a href="https://twitter.com/kpschrade/status/289040379800592384">I asked a question on Twitter</a> on why some of the recommend max_input_time settings seem to be ridiculously large.  Some of the defaults I've seen have been upwards of 60 seconds.  However, after thinking about it I was a little confused as to why a C program (i.e. PHP) would take so long to process string input. The reason I was thinking about this was because I was thinking about ways to protect PHP from denial of service attacks. 
</blockquote>
<p>
So he ran some tests to see just how effective changes in this setting could be and how much time a typical PHP request would need to take in input. Using a Zend Framework 2 HTTP client, he simulated POSTS and tracked the start and end times for a file upload. He includes the timing results in the post based on both this setup and a change to only post regular text-based form data.
</p>]]></description>
      <pubDate>Fri, 11 Jan 2013 09:20:46 -0600</pubDate>
    </item>
  </channel>
</rss>
