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.

117 lines
3.4 KiB

#ifndef LI_H2_H
#define LI_H2_H
#include "first.h"
#include "sys-time.h"
#include "base_decls.h"
#include "buffer.h"
#include "ls-hpack/lshpack.h"
struct chunkqueue; /* declaration */
typedef enum {
H2_FTYPE_DATA = 0x00,
H2_FTYPE_HEADERS = 0x01,
H2_FTYPE_PRIORITY = 0x02,
H2_FTYPE_RST_STREAM = 0x03,
H2_FTYPE_SETTINGS = 0x04,
H2_FTYPE_PUSH_PROMISE = 0x05,
H2_FTYPE_PING = 0x06,
H2_FTYPE_GOAWAY = 0x07,
H2_FTYPE_WINDOW_UPDATE = 0x08,
H2_FTYPE_CONTINUATION = 0x09
} request_h2ftype_t;
typedef enum {
H2_SETTINGS_HEADER_TABLE_SIZE = 0x01,
H2_SETTINGS_ENABLE_PUSH = 0x02,
H2_SETTINGS_MAX_CONCURRENT_STREAMS = 0x03,
H2_SETTINGS_INITIAL_WINDOW_SIZE = 0x04,
H2_SETTINGS_MAX_FRAME_SIZE = 0x05,
H2_SETTINGS_MAX_HEADER_LIST_SIZE = 0x06
} request_h2settings_t;
typedef enum {
H2_FLAG_END_STREAM = 0x01, /* DATA HEADERS */
H2_FLAG_END_HEADERS = 0x04, /* HEADERS PUSH_PROMISE CONTINUATION */
H2_FLAG_PADDED = 0x08, /* DATA HEADERS PUSH_PROMISE */
H2_FLAG_PRIORITY = 0x20, /* HEADERS */
H2_FLAG_ACK = 0x01 /* PING SETTINGS*/
} request_h2flag_t;
typedef enum {
H2_E_NO_ERROR = 0x00,
H2_E_PROTOCOL_ERROR = 0x01,
H2_E_INTERNAL_ERROR = 0x02,
H2_E_FLOW_CONTROL_ERROR = 0x03,
H2_E_SETTINGS_TIMEOUT = 0x04,
H2_E_STREAM_CLOSED = 0x05,
H2_E_FRAME_SIZE_ERROR = 0x06,
H2_E_REFUSED_STREAM = 0x07,
H2_E_CANCEL = 0x08,
H2_E_COMPRESSION_ERROR = 0x09,
H2_E_CONNECT_ERROR = 0x0a,
H2_E_ENHANCE_YOUR_CALM = 0x0b,
H2_E_INADEQUATE_SECURITY = 0x0c,
H2_E_HTTP_1_1_REQUIRED = 0x0d
} request_h2error_t;
typedef enum {
H2_STATE_IDLE,
H2_STATE_RESERVED_LOCAL,
H2_STATE_RESERVED_REMOTE,
H2_STATE_OPEN,
H2_STATE_HALF_CLOSED_LOCAL,
H2_STATE_HALF_CLOSED_REMOTE,
H2_STATE_CLOSED
} request_h2state_t;
struct h2con {
request_st *r[8];
uint32_t rused;
uint32_t h2_cid;
uint32_t h2_sid;
int32_t sent_goaway;
[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/
12 months ago
unix_time64_t sent_settings;
uint32_t s_header_table_size; /* SETTINGS_HEADER_TABLE_SIZE */
uint32_t s_enable_push; /* SETTINGS_ENABLE_PUSH */
uint32_t s_max_concurrent_streams; /* SETTINGS_MAX_CONCURRENT_STREAMS */
int32_t s_initial_window_size; /* SETTINGS_INITIAL_WINDOW_SIZE */
uint32_t s_max_frame_size; /* SETTINGS_MAX_FRAME_SIZE */
uint32_t s_max_header_list_size; /* SETTINGS_MAX_HEADER_LIST_SIZE */
struct lshpack_dec decoder;
struct lshpack_enc encoder;
[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/
12 months ago
unix_time64_t half_closed_ts;
};
void h2_send_goaway (connection *con, request_h2error_t e);
int h2_parse_frames (connection *con);
int h2_want_read (connection *con);
void h2_init_con (request_st * restrict h2r, connection * restrict con, const buffer * restrict http2_settings);
int h2_send_1xx (request_st *r, connection *con);
void h2_send_100_continue (request_st *r, connection *con);
void h2_send_headers (request_st *r, connection *con);
void h2_send_cqdata (request_st *r, connection *con, struct chunkqueue *cq, uint32_t dlen);
void h2_send_end_stream (request_st *r, connection *con);
void h2_retire_stream (request_st *r, connection *con);
void h2_retire_con (request_st *h2r, connection *con);
__attribute_cold__
__attribute_noinline__
int h2_check_con_upgrade_h2c (request_st *r);
#endif