lighttpd 1.4.x https://www.lighttpd.net/
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

204 lines
4.8 KiB

#ifndef _BASE_H_
#define _BASE_H_
#include "first.h"
#include "sys-time.h"
#include "base_decls.h"
#include "buffer.h"
#include "array.h"
#include "chunk.h"
#include "http_kv.h"
#include "request.h"
#include "sock_addr.h"
struct fdevents; /* declaration */
struct server_socket; /* declaration */
struct connection {
request_st request;
h2con *h2;
int fd; /* the FD for this connection */
fdnode *fdn; /* fdevent (fdnode *) object */
connection *jqnext;
/* fd states */
signed char is_readable;
signed char is_writable;
char is_ssl_sock;
char traffic_limit_reached;
uint16_t revents_err;
uint16_t proto_default_port;
chunkqueue *write_queue; /* a large queue for low-level write ( HTTP response ) [ file, mem ] */
chunkqueue *read_queue; /* a small queue for low-level read ( HTTP request ) [ mem ] */
off_t bytes_written; /* used by mod_accesslog, mod_rrd */
off_t bytes_written_cur_second; /* used by mod_accesslog, mod_rrd */
off_t bytes_read; /* used by mod_accesslog, mod_rrd */
int (* network_write)(struct connection *con, chunkqueue *cq, off_t max_bytes);
int (* network_read)(struct connection *con, chunkqueue *cq, off_t max_bytes);
handler_t (* reqbody_read)(struct request_st *r);
server *srv;
void *plugin_slots;
void **plugin_ctx; /* plugin connection specific config */
void *config_data_base;
sock_addr dst_addr;
buffer dst_addr_buf;
const struct server_socket *srv_socket; /* reference to the server-socket */
/* timestamps */
[multiple] Y2038 32-bit signed time_t mitigations Most OS platforms have already provided solutions to Y2038 32-bit signed time_t 5 - 10 years ago (or more!) Notable exceptions are Linux i686 and FreeBSD i386. Since 32-bit systems tend to be embedded systems, and since many distros take years to pick up new software, this commit aims to provide Y2038 mitigations for lighttpd running on 32-bit systems with Y2038-unsafe 32-bit signed time_t * Y2038: lighttpd 1.4.60 and later report Y2038 safety $ lighttpd -V + Y2038 support # Y2038-SAFE $ lighttpd -V - Y2038 support (unsafe 32-bit signed time_t) # Y2038-UNSAFE * Y2038: general platform info * Y2038-SAFE: lighttpd 64-bit builds on platforms using 64-bit time_t - all major 64-bit platforms (known to this author) use 64-bit time_t * Y2038-SAFE: lighttpd 32-bit builds on platforms using 64-bit time_t - Linux x32 ABI (different from i686) - FreeBSD all 32-bit and 64-bit architectures *except* 32-bit i386 - NetBSD 6.0 (released Oct 2012) all 32-bit and 64-bit architectures - OpenBSD 5.5 (released May 2014) all 32-bit and 64-bit architectures - Microsoft Windows XP and Visual Studio 2005 (? unsure ?) Another reference suggests Visual Studio 2015 defaults to 64-bit time_t - MacOS 10.15 Catalina (released 2019) drops support for 32-bit apps * Y2038-SAFE: lighttpd 32-bit builds on platforms using 32-bit unsigned time_t - e.g. OpenVMS (unknown if lighttpd builds on this platform) * Y2038-UNSAFE: lighttpd 32-bit builds on platforms using 32-bit signed time_t - Linux 32-bit (including i686) - glibc 32-bit library support not yet available for 64-bit time_t - https://sourceware.org/glibc/wiki/Y2038ProofnessDesign - Linux kernel 5.6 on 32-bit platforms does support 64-bit time_t https://itsubuntu.com/linux-kernel-5-6-to-fix-the-year-2038-issue-unix-y2k/ - https://www.gnu.org/software/libc/manual/html_node/64_002dbit-time-symbol-handling.html "Note: at this point, 64-bit time support in dual-time configurations is work-in-progress, so for these configurations, the public API only makes the 32-bit time support available. In a later change, the public API will allow user code to choose the time size for a given compilation unit." - compiling with -D_TIME_BITS=64 currently has no effect - glibc recent (Jul 2021) mailing list discussion - https://public-inbox.org/bug-gnulib/878s2ozq70.fsf@oldenburg.str.redhat.com/T/ - FreeBSD i386 - DragonFlyBSD 32-bit * Y2038 mitigations attempted on Y2038-UNSAFE platforms (32-bit signed time_t) * lighttpd prefers system monotonic clock instead of realtime clock in places where realtime clock is not required * lighttpd treats negative time_t values as after 19 Jan 2038 03:14:07 GMT * (lighttpd presumes that lighttpd will not encounter dates before 1970 during normal operation.) * lighttpd casts struct stat st.st_mtime (and st.st_*time) through uint64_t to convert negative timestamps for comparisions with 64-bit timestamps (treating negative timestamp values as after 19 Jan 2038 03:14:07 GMT) * lighttpd provides unix_time64_t (int64_t) and * lighttpd provides struct unix_timespec64 (unix_timespec64_t) (struct timespec equivalent using unix_time64_t tv_sec member) * lighttpd provides gmtime64_r() and localtime64_r() wrappers for platforms 32-bit platforms using 32-bit time_t and lighttpd temporarily shifts the year in order to use gmtime_r() and localtime_r() (or gmtime() and localtime()) from standard libraries, before readjusting year and passing struct tm to formatting functions such as strftime() * lighttpd provides TIME64_CAST() macro to cast signed 32-bit time_t to unsigned 32-bit and then to unix_time64_t * Note: while lighttpd tries handle times past 19 Jan 2038 03:14:07 GMT on 32-bit platforms using 32-bit signed time_t, underlying libraries and underlying filesystems might not behave properly after 32-bit signed time_t overflows (19 Jan 2038 03:14:08 GMT). If a given 32-bit OS does not work properly using negative time_t values, then lighttpd likely will not work properly on that system. * Other references and blogs - https://en.wikipedia.org/wiki/Year_2038_problem - https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs - http://www.lieberbiber.de/2017/03/14/a-look-at-the-year-20362038-problems-and-time-proofness-in-various-systems/
5 months ago
unix_time64_t read_idle_ts;
unix_time64_t close_timeout_ts;
unix_time64_t write_request_ts;
unix_time64_t connection_start;
uint32_t request_count; /* number of requests handled in this connection */
int keep_alive_idle; /* remember max_keep_alive_idle from config */
connection *next;
connection *prev;
};
/* log_con_jqueue is in log.c to be defined in shared object */
#define joblist_append(con) connection_jq_append(con)
extern connection *log_con_jqueue;
static inline void connection_jq_append(connection * const restrict con);
static inline void connection_jq_append(connection * const restrict con)
{
if (!con->jqnext) {
con->jqnext = log_con_jqueue;
log_con_jqueue = con;
}
}
typedef struct {
/*(used sparsely, if at all, after config at startup)*/
uint32_t max_request_field_size;
unsigned char log_request_header_on_error;
unsigned char http_header_strict;
unsigned char http_host_strict;
unsigned char http_host_normalize;
unsigned char http_method_get_body;
unsigned char high_precision_timestamps;
unsigned char h2proto;
unsigned char absolute_dir_redirect;
unsigned short http_url_normalize;
unsigned short max_worker;
unsigned short max_fds;
unsigned short max_conns;
unsigned short port;
unsigned int upload_temp_file_size;
array *upload_tempdirs;
unsigned char dont_daemonize;
unsigned char preflight_check;
unsigned char enable_cores;
unsigned char compat_module_load;
unsigned char config_deprecated;
unsigned char config_unsupported;
unsigned char systemd_socket_activation;
unsigned char errorlog_use_syslog;
const buffer *syslog_facility;
const buffer *bindhost;
const buffer *changeroot;
const buffer *username;
const buffer *groupname;
const buffer *network_backend;
const array *feature_flags;
const char *event_handler;
buffer *pid_file;
buffer *modules_dir;
array *modules;
array *config_touched;
array empty_array;
} server_config;
typedef struct server_socket {
sock_addr addr;
int fd;
uint8_t is_ssl;
uint8_t srv_token_colon;
unsigned short sidx;
fdnode *fdn;
server *srv;
buffer *srv_token;
} server_socket;
typedef struct {
server_socket **ptr;
uint32_t size;
uint32_t used;
} server_socket_array;
struct server {
void *plugin_slots;
array *config_context;
int config_captures;
struct fdevents *ev;
int (* network_backend_write)(int fd, chunkqueue *cq, off_t max_bytes, log_error_st *errh);
handler_t (* request_env)(request_st *r);
/* buffers */
buffer *tmp_buf;
/* counters */
int con_opened;
int con_read;
int con_written;
int con_closed;
int max_fds; /* max possible fds */
int max_fds_lowat;/* low watermark */
int max_fds_hiwat;/* high watermark */
int cur_fds; /* currently used fds */
int sockets_disabled;
uint32_t lim_conns;
connection *conns;
connection *conns_pool;
log_error_st *errh;
[multiple] Y2038 32-bit signed time_t mitigations Most OS platforms have already provided solutions to Y2038 32-bit signed time_t 5 - 10 years ago (or more!) Notable exceptions are Linux i686 and FreeBSD i386. Since 32-bit systems tend to be embedded systems, and since many distros take years to pick up new software, this commit aims to provide Y2038 mitigations for lighttpd running on 32-bit systems with Y2038-unsafe 32-bit signed time_t * Y2038: lighttpd 1.4.60 and later report Y2038 safety $ lighttpd -V + Y2038 support # Y2038-SAFE $ lighttpd -V - Y2038 support (unsafe 32-bit signed time_t) # Y2038-UNSAFE * Y2038: general platform info * Y2038-SAFE: lighttpd 64-bit builds on platforms using 64-bit time_t - all major 64-bit platforms (known to this author) use 64-bit time_t * Y2038-SAFE: lighttpd 32-bit builds on platforms using 64-bit time_t - Linux x32 ABI (different from i686) - FreeBSD all 32-bit and 64-bit architectures *except* 32-bit i386 - NetBSD 6.0 (released Oct 2012) all 32-bit and 64-bit architectures - OpenBSD 5.5 (released May 2014) all 32-bit and 64-bit architectures - Microsoft Windows XP and Visual Studio 2005 (? unsure ?) Another reference suggests Visual Studio 2015 defaults to 64-bit time_t - MacOS 10.15 Catalina (released 2019) drops support for 32-bit apps * Y2038-SAFE: lighttpd 32-bit builds on platforms using 32-bit unsigned time_t - e.g. OpenVMS (unknown if lighttpd builds on this platform) * Y2038-UNSAFE: lighttpd 32-bit builds on platforms using 32-bit signed time_t - Linux 32-bit (including i686) - glibc 32-bit library support not yet available for 64-bit time_t - https://sourceware.org/glibc/wiki/Y2038ProofnessDesign - Linux kernel 5.6 on 32-bit platforms does support 64-bit time_t https://itsubuntu.com/linux-kernel-5-6-to-fix-the-year-2038-issue-unix-y2k/ - https://www.gnu.org/software/libc/manual/html_node/64_002dbit-time-symbol-handling.html "Note: at this point, 64-bit time support in dual-time configurations is work-in-progress, so for these configurations, the public API only makes the 32-bit time support available. In a later change, the public API will allow user code to choose the time size for a given compilation unit." - compiling with -D_TIME_BITS=64 currently has no effect - glibc recent (Jul 2021) mailing list discussion - https://public-inbox.org/bug-gnulib/878s2ozq70.fsf@oldenburg.str.redhat.com/T/ - FreeBSD i386 - DragonFlyBSD 32-bit * Y2038 mitigations attempted on Y2038-UNSAFE platforms (32-bit signed time_t) * lighttpd prefers system monotonic clock instead of realtime clock in places where realtime clock is not required * lighttpd treats negative time_t values as after 19 Jan 2038 03:14:07 GMT * (lighttpd presumes that lighttpd will not encounter dates before 1970 during normal operation.) * lighttpd casts struct stat st.st_mtime (and st.st_*time) through uint64_t to convert negative timestamps for comparisions with 64-bit timestamps (treating negative timestamp values as after 19 Jan 2038 03:14:07 GMT) * lighttpd provides unix_time64_t (int64_t) and * lighttpd provides struct unix_timespec64 (unix_timespec64_t) (struct timespec equivalent using unix_time64_t tv_sec member) * lighttpd provides gmtime64_r() and localtime64_r() wrappers for platforms 32-bit platforms using 32-bit time_t and lighttpd temporarily shifts the year in order to use gmtime_r() and localtime_r() (or gmtime() and localtime()) from standard libraries, before readjusting year and passing struct tm to formatting functions such as strftime() * lighttpd provides TIME64_CAST() macro to cast signed 32-bit time_t to unsigned 32-bit and then to unix_time64_t * Note: while lighttpd tries handle times past 19 Jan 2038 03:14:07 GMT on 32-bit platforms using 32-bit signed time_t, underlying libraries and underlying filesystems might not behave properly after 32-bit signed time_t overflows (19 Jan 2038 03:14:08 GMT). If a given 32-bit OS does not work properly using negative time_t values, then lighttpd likely will not work properly on that system. * Other references and blogs - https://en.wikipedia.org/wiki/Year_2038_problem - https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs - http://www.lieberbiber.de/2017/03/14/a-look-at-the-year-20362038-problems-and-time-proofness-in-various-systems/
5 months ago
unix_time64_t loadts;
double loadavg[3];
/* members used at start-up or rarely used */
server_config srvconf;
void *config_data_base;
server_socket_array srv_sockets;
server_socket_array srv_sockets_inherited;
struct { void *ptr; uint32_t used; uint32_t size; } plugins;
[multiple] Y2038 32-bit signed time_t mitigations Most OS platforms have already provided solutions to Y2038 32-bit signed time_t 5 - 10 years ago (or more!) Notable exceptions are Linux i686 and FreeBSD i386. Since 32-bit systems tend to be embedded systems, and since many distros take years to pick up new software, this commit aims to provide Y2038 mitigations for lighttpd running on 32-bit systems with Y2038-unsafe 32-bit signed time_t * Y2038: lighttpd 1.4.60 and later report Y2038 safety $ lighttpd -V + Y2038 support # Y2038-SAFE $ lighttpd -V - Y2038 support (unsafe 32-bit signed time_t) # Y2038-UNSAFE * Y2038: general platform info * Y2038-SAFE: lighttpd 64-bit builds on platforms using 64-bit time_t - all major 64-bit platforms (known to this author) use 64-bit time_t * Y2038-SAFE: lighttpd 32-bit builds on platforms using 64-bit time_t - Linux x32 ABI (different from i686) - FreeBSD all 32-bit and 64-bit architectures *except* 32-bit i386 - NetBSD 6.0 (released Oct 2012) all 32-bit and 64-bit architectures - OpenBSD 5.5 (released May 2014) all 32-bit and 64-bit architectures - Microsoft Windows XP and Visual Studio 2005 (? unsure ?) Another reference suggests Visual Studio 2015 defaults to 64-bit time_t - MacOS 10.15 Catalina (released 2019) drops support for 32-bit apps * Y2038-SAFE: lighttpd 32-bit builds on platforms using 32-bit unsigned time_t - e.g. OpenVMS (unknown if lighttpd builds on this platform) * Y2038-UNSAFE: lighttpd 32-bit builds on platforms using 32-bit signed time_t - Linux 32-bit (including i686) - glibc 32-bit library support not yet available for 64-bit time_t - https://sourceware.org/glibc/wiki/Y2038ProofnessDesign - Linux kernel 5.6 on 32-bit platforms does support 64-bit time_t https://itsubuntu.com/linux-kernel-5-6-to-fix-the-year-2038-issue-unix-y2k/ - https://www.gnu.org/software/libc/manual/html_node/64_002dbit-time-symbol-handling.html "Note: at this point, 64-bit time support in dual-time configurations is work-in-progress, so for these configurations, the public API only makes the 32-bit time support available. In a later change, the public API will allow user code to choose the time size for a given compilation unit." - compiling with -D_TIME_BITS=64 currently has no effect - glibc recent (Jul 2021) mailing list discussion - https://public-inbox.org/bug-gnulib/878s2ozq70.fsf@oldenburg.str.redhat.com/T/ - FreeBSD i386 - DragonFlyBSD 32-bit * Y2038 mitigations attempted on Y2038-UNSAFE platforms (32-bit signed time_t) * lighttpd prefers system monotonic clock instead of realtime clock in places where realtime clock is not required * lighttpd treats negative time_t values as after 19 Jan 2038 03:14:07 GMT * (lighttpd presumes that lighttpd will not encounter dates before 1970 during normal operation.) * lighttpd casts struct stat st.st_mtime (and st.st_*time) through uint64_t to convert negative timestamps for comparisions with 64-bit timestamps (treating negative timestamp values as after 19 Jan 2038 03:14:07 GMT) * lighttpd provides unix_time64_t (int64_t) and * lighttpd provides struct unix_timespec64 (unix_timespec64_t) (struct timespec equivalent using unix_time64_t tv_sec member) * lighttpd provides gmtime64_r() and localtime64_r() wrappers for platforms 32-bit platforms using 32-bit time_t and lighttpd temporarily shifts the year in order to use gmtime_r() and localtime_r() (or gmtime() and localtime()) from standard libraries, before readjusting year and passing struct tm to formatting functions such as strftime() * lighttpd provides TIME64_CAST() macro to cast signed 32-bit time_t to unsigned 32-bit and then to unix_time64_t * Note: while lighttpd tries handle times past 19 Jan 2038 03:14:07 GMT on 32-bit platforms using 32-bit signed time_t, underlying libraries and underlying filesystems might not behave properly after 32-bit signed time_t overflows (19 Jan 2038 03:14:08 GMT). If a given 32-bit OS does not work properly using negative time_t values, then lighttpd likely will not work properly on that system. * Other references and blogs - https://en.wikipedia.org/wiki/Year_2038_problem - https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs - http://www.lieberbiber.de/2017/03/14/a-look-at-the-year-20362038-problems-and-time-proofness-in-various-systems/
5 months ago
unix_time64_t startup_ts;
unix_time64_t graceful_expire_ts;
uid_t uid;
gid_t gid;
pid_t pid;
int stdin_fd;
[core] graceful and immediate restart option graceful and (nearly) immediate lighttpd restart option For *some* configurations, it *may* be safe to background the current lighttpd server (or workers) to continue processing active requests and, in parallel, to start up a new lighttpd server with a new configuration. For other configurations, doing so might not be safe! Therefore, this option must be explicitly configured to enable: server.feature-flags += ("server.graceful-restart-bg" => "enable") server.systemd-socket-activation = "enable" Along with enabling server.feature-flags "server.graceful-restart-bg", enabling server.systemd-socket-activation allows transfer of open listening sockets to the new lighttpd server instance, and occurs without closing the listening sockets and without destroying the kernel listen backlog queue on the socket. Safe configurations may include lighttpd.conf which connect to standalone backend daemons, e.g. proxying to other servers, including PHP-FPM backends. Unsafe configurations include lighttpd.conf which use "bin-path" option in *.server configs, instructing lighttpd to execute the backends. Using the graceful-and-immediate-restart option is likely *unsafe* if the backend daemon expects only one instance of itself to run at a time. Current implementation of graceful and immediate restart option keeps the backgrounded lighttpd in the same process group, so that subsequent SIGINT or SIGTERM will shut down both the new and the backgrounded servers. (An alternative option (commented out in the code) is to background and detach from the new lighttpd process.) Regardless, existing subprocesses, such as CGI, remain in original process group. As a result, the new lighttpd server may receive SIGCHLD for unknown processes inherited from the old server, which the new lighttpd server will reap and discard. The original lighttpd server, now a child, will be unable to detect exit or reap and report status on those pre-existing subprocesses. Graceful restart is triggered in lighttpd by sending lighttpd SIGUSR1. If lighttpd is configured with workers, then SIGINT (not SIGUSR1) is sent to the process group, including other processes started by lighttpd, e.g. CGI. To work well with graceful restart, CGI scripts and other processes should trap SIGINT (and SIGUSR1 for good measure). Long-running scripts may want to checkpoint and close, e.g. a CGI script implementing a long-running websocket connection.
1 year ago
char **argv;
#ifdef HAVE_PCRE2_H
void *match_data; /*(shared and reused)*/
#endif
};
#endif