Make tests pass after 2035

[bmwiedemann]

I could not test if it still passes on i586, but if the test fails there, you want to see that anyway.

Background:
As part of my work on reproducible builds for openSUSE, I check that software still gives identical build results in the future.
The usual offset is +15 years, because that is how long I expect some software will be used in some places.
This showed up failing tests in our package build.
See https://reproducible-builds.org/ for why this matters.

[gstrauss]

Thanks for taking a look.

This showed up failing tests in our package build.

Would you please provide more details of the input, environment, and the error messages? Were your builds 32-bit or 64-bit? On 64-bit Linux, time_t should be 64-bit. What time was on the system you tested in your test environment? If the system time was after 2036, then that would explain what you are seeing from the lighttpd tests, which assume 2036 is in the future. If that is the case, then it might be better to modifiy the tests to take current system time as baseline and add or subtract a delta when creating the timestamp to use in the tests.

[bmwiedemann]

Yes, the test deliberately runs in 2036. Doing the math should also fix it, but is slightly less straight-forward. What would be the advantage of that approach?

[gstrauss]

What would be the advantage of that approach?

It would be more self-documenting of the intention, and would continue to work (today) on 32-bit systems with 32-bit time_t. Your current patch works only for 64-bit time_t. lighttpd (today) runs on 32-bit embedded systems, and I do not want the tests to break in the present "now".

[bmwiedemann]

So that means, today's lighttpd breaks in under 17 years on these devices... Sounds like a timebomb waiting there... and cookies can be set to expire well in the future, so maybe it is only 7 years for some applications?

[gstrauss]

If operating system time_t is a signed 32-bit integer, then Y2038 (Jan 19, 2038) is an issue for that device.

lighttpd has no internal limitation of its own, but uses the system time_t. In fact, certain parts of lighttpd have taken pains to treat 32-bit signed time_t as unsigned so that those modules that encode time_t in 8 hex chars will continue to work until the year 2106.

[bmwiedemann]

So would these tests pass with a year of 2105?

[gstrauss]

So would these tests pass with a year of 2105?

I think you have misunderstood what I have written about Y2038, but that is besides the point of this PR.

The tests pass when run today. Any changes to the tests should continue to pass when run today.

The tests in question currently set a hard-coded date that is (currently) many years in the future. When you violate that by setting your system time further into the future, the tests fail. Since the tests in question need a time that is in the future, one proper solution which I have proposed is to calculate that time in the future based on the reported system time.

Doing the math should also fix it, but is slightly less straight-forward.

It took all of 10 seconds to implement the one line of Perl code to do that: my $nextyr = (gmtime(time()))[5] + 1900 + 1;

--- a/tests/request.t
+++ b/tests/request.t
@@ -460,10 +460,12 @@ EOF
 $t->{RESPONSE} = [ { 'HTTP-Protocol' => 'HTTP/1.0', 'HTTP-Status' => 400 } ];
 ok($tf->handle_http($t) == 0, 'OPTIONS for RTSP');
 
+my $nextyr = (gmtime(time()))[5] + 1900 + 1;
+
 $t->{REQUEST}  = ( <<EOF
 GET /index.html HTTP/1.0
-If-Modified-Since: Sun, 01 Jan 2036 00:00:02 GMT
-If-Modified-Since: Sun, 01 Jan 2036 00:00:02 GMT
+If-Modified-Since: Sun, 01 Jan $nextyr 00:00:02 GMT
+If-Modified-Since: Sun, 01 Jan $nextyr 00:00:02 GMT
 EOF
  );
 $t->{RESPONSE} = [ { 'HTTP-Protocol' => 'HTTP/1.0', 'HTTP-Status' => 304 } ];
@@ -484,8 +486,8 @@ ok($tf->handle_http($t) == 0, 'broken If-Modified-Since');
 
 $t->{REQUEST}  = ( <<EOF
 GET /index.html HTTP/1.0
-If-Modified-Since2: Sun, 01 Jan 2036 00:00:03 GMT
-If-Modified-Since: Sun, 01 Jan 2036 00:00:02 GMT
+If-Modified-Since2: Sun, 01 Jan $nextyr 00:00:03 GMT
+If-Modified-Since: Sun, 01 Jan $nextyr 00:00:02 GMT
 EOF
  );
 $t->{RESPONSE} = [ { 'HTTP-Protocol' => 'HTTP/1.0', 'HTTP-Status' => 304 } ];
@@ -493,7 +495,7 @@ ok($tf->handle_http($t) == 0, 'Similar Headers (bug #1287)');
 
 $t->{REQUEST}  = ( <<EOF
 GET /index.html HTTP/1.0
-If-Modified-Since: Sun, 01 Jan 2036 00:00:02 GMT
+If-Modified-Since: Sun, 01 Jan $nextyr 00:00:02 GMT
 EOF
  );
 $t->{RESPONSE} = [ { 'HTTP-Protocol' => 'HTTP/1.0', 'HTTP-Status' => 304, 'Content-Type' => 'text/html' } ];
@@ -501,7 +503,7 @@ ok($tf->handle_http($t) == 0, 'If-Modified-Since');
 
 $t->{REQUEST}  = ( <<EOF
 GET /index.html HTTP/1.0
-If-Modified-Since: Sun, 01 Jan 2036 00:00:02 GMT
+If-Modified-Since: Sun, 01 Jan $nextyr 00:00:02 GMT
 EOF
  );
 $t->{RESPONSE} = [ { 'HTTP-Protocol' => 'HTTP/1.0', 'HTTP-Status' => 304, '-Content-Length' => '' } ];

[bmwiedemann]

OK. I updated the commit accordingly.

[bmwiedemann]

Test also looks good.

[gstrauss]

My dev branch contains a commit of the changes I proposed. This PR will close automatically once my dev branch is pushed to lighttpd git master, which I intend to do later in August.