Christoph Biedl wrote... > Holger Levsen wrote...
> > Besides this, you didnt have any issues with munin 2.0?
(...)
> Sure more things to come ...
I knew there was another thing ... again the expiration date in the
HTTP response, see #601200. Yes, Tom Feiner was right, it's RFC 2616.
Problem is: The locale settings effective when starting the http
daemon (at least lighttpd) are propagated to munin-cgi-graph, and
finally to strftime in get_w3c_date_from_epoch. This might create an
weekday that does not match the list in the RFC:
HTTP request sent, awaiting response...
HTTP/1.0 200 OK
(...)
Expires: So, 11 Dez 2011 16:45:00 GMT
Connection: keep-alive
Date: Sun, 11 Dec 2011 16:41:26 GMT
Server: lighttpd/1.4.28
Length: 14304 (14K) [image/png]
Saving to: `/dev/null'
100%[======================================>] 14.304 --.-K/s in
0,001s
Last-modified header invalid -- time-stamp ignored.
I had similar issues in other packets, nagios and gdm to name a few.
While one might argue daemons might not be started with a locale
different from C, or a daemon should clear the environment in appropriate
places, I'd just suggest to utilize the idea of the robustness principle:
--- a/munin-cgi-graph
+++ b/munin-cgi-graph
@@ -28,7 +28,7 @@ use strict;
use warnings;
use IO::Handle;
use Date::Manip;
-use POSIX qw(strftime);
+use POSIX qw(strftime locale_h);
use CGI::Fast qw(:cgi);
use CGI::Carp qw(fatalsToBrowser);
use Time::HiRes qw(gettimeofday tv_interval);
@@ -67,6 +67,7 @@ logger_open($config->{'logdir'});
logger_debug() if defined($ENV{CGI_DEBUG});
# BEGIN FAST-CGI LOOP:
+setlocale (LC_TIME, 'C');
my $nb_request = 0;
my $nb_request_max = 0;
while (new CGI::Fast) {
Cheers,
Christoph
signature.asc
Description: Digital signature
