PHPDeveloper.org

Kevin Schroeder: Setting max_input_time (with data!)

Fri, 11 Jan 2013 09:20:46 -0600

Kevin Schroeder has a new post to his site today wondering about the "max_input_time" setting for PHP and why some recommend it being a large number despite the (usually) fast time PHP has accepting input.

I asked a question on Twitter 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.

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.

Brian Moon's Blog: Errors when adding/subtracing dates using seconds

Tue, 17 Jan 2012 11:19:22 -0600

Brian Moon has a reminder about date handling in PHP - days are not always 86400 seconds long, sometimes there's "leap seconds" included too. Thankfully, there's easy ways around it:

The problem with this is that it assume that there are only 86400 seconds in every day. There are in fact not. On days when the clocks change for daylight savings time, there are either 1 hour more than that or 1 hour less than that. In addition, there are also leap seconds put into our time system to keep us in line with the sun. There is one this year, 2012, on June 30th in fact. Since they don't happen with the regularity that daylight savings time does, it may be easy to forget those. Luckily, for this problem, the solution is the same.

His first solution involves letting strtotime do the work for him, internally calculating the leap seconds or any other issue that might come up. As an alternate solution, he also mentions "doing your math at noon" - this gives you enough leeway to make the offset leap seconds could cause a much smaller risk.

Derick Rethans' Blog: PHP lags 23 seconds

Wed, 11 Jan 2006 06:41:13 -0600

In this new post on his blog today, Derick Rethans points out something that might confuse some when it comes to date/time handling - a few seconds of "lag".

Bug report #35958 must have the most obscure one ever:

"strftime usually returns a string from the number of seconds since 1 jan 1970. Now, it lags and returns a string representing 23 seconds too late."

If you know what's going on though, it isn't really that weird.

He talks about the leap seconds that have been added to keep things straight, and how that's affecting PHP's built-in date/time functionality. He also shows an example of how you can get the "more correct" time versus the normal output...