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.

1324 lines
49 KiB

#include "first.h"
#include "sys-time.h"
#include "base.h"
#include "array.h"
#include "buffer.h"
#include "chunk.h"
#include "fdevent.h"
#include "log.h"
#include "http_chunk.h"
#include "http_cgi.h"
#include "http_date.h"
#include "http_etag.h"
#include "http_header.h"
#include "response.h"
#include "sock_addr.h"
#include "stat_cache.h"
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include "sys-socket.h"
#include <unistd.h>
/**
* max size of the HTTP response header from backends
* (differs from server.max-request-field-size for max request field size)
*/
#define MAX_HTTP_RESPONSE_FIELD_SIZE 65535
__attribute_cold__
int http_response_buffer_append_authority(request_st * const r, buffer * const o) {
[multiple] reduce redundant NULL buffer checks This commit is a large set of code changes and results in removal of hundreds, perhaps thousands, of CPU instructions, a portion of which are on hot code paths. Most (buffer *) used by lighttpd are not NULL, especially since buffers were inlined into numerous larger structs such as request_st and chunk. In the small number of instances where that is not the case, a NULL check is often performed earlier in a function where that buffer is later used with a buffer_* func. In the handful of cases that remained, a NULL check was added, e.g. with r->http_host and r->conf.server_tag. - check for empty strings at config time and set value to NULL if blank string will be ignored at runtime; at runtime, simple pointer check for NULL can be used to check for a value that has been set and is not blank ("") - use buffer_is_blank() instead of buffer_string_is_empty(), and use buffer_is_unset() instead of buffer_is_empty(), where buffer is known not to be NULL so that NULL check can be skipped - use buffer_clen() instead of buffer_string_length() when buffer is known not to be NULL (to avoid NULL check at runtime) - use buffer_truncate() instead of buffer_string_set_length() to truncate string, and use buffer_extend() to extend Examples where buffer known not to be NULL: - cpv->v.b from config_plugin_values_init is not NULL if T_CONFIG_BOOL (though we might set it to NULL if buffer_is_blank(cpv->v.b)) - address of buffer is arg (&foo) (compiler optimizer detects this in most, but not all, cases) - buffer is checked for NULL earlier in func - buffer is accessed in same scope without a NULL check (e.g. b->ptr) internal behavior change: callers must not pass a NULL buffer to some funcs. - buffer_init_buffer() requires non-null args - buffer_copy_buffer() requires non-null args - buffer_append_string_buffer() requires non-null args - buffer_string_space() requires non-null arg
8 months ago
if (!buffer_is_blank(&r->uri.authority)) {
buffer_append_string_buffer(o, &r->uri.authority);
} else {
/* get the name of the currently connected socket */
sock_addr our_addr;
socklen_t our_addr_len;
our_addr.plain.sa_family = 0;
our_addr_len = sizeof(our_addr);
if (-1 == getsockname(r->con->fd, (struct sockaddr *)&our_addr, &our_addr_len)
|| our_addr_len > (socklen_t)sizeof(our_addr)) {
r->http_status = 500;
log_perror(r->conf.errh, __FILE__, __LINE__, "can't get sockname");
return -1;
}
if (our_addr.plain.sa_family == AF_INET
&& our_addr.ipv4.sin_addr.s_addr == htonl(INADDR_LOOPBACK)) {
static char lhost[32];
static size_t lhost_len = 0;
if (0 != lhost_len) {
buffer_append_string_len(o, lhost, lhost_len);
}
else {
[multiple] reduce redundant NULL buffer checks This commit is a large set of code changes and results in removal of hundreds, perhaps thousands, of CPU instructions, a portion of which are on hot code paths. Most (buffer *) used by lighttpd are not NULL, especially since buffers were inlined into numerous larger structs such as request_st and chunk. In the small number of instances where that is not the case, a NULL check is often performed earlier in a function where that buffer is later used with a buffer_* func. In the handful of cases that remained, a NULL check was added, e.g. with r->http_host and r->conf.server_tag. - check for empty strings at config time and set value to NULL if blank string will be ignored at runtime; at runtime, simple pointer check for NULL can be used to check for a value that has been set and is not blank ("") - use buffer_is_blank() instead of buffer_string_is_empty(), and use buffer_is_unset() instead of buffer_is_empty(), where buffer is known not to be NULL so that NULL check can be skipped - use buffer_clen() instead of buffer_string_length() when buffer is known not to be NULL (to avoid NULL check at runtime) - use buffer_truncate() instead of buffer_string_set_length() to truncate string, and use buffer_extend() to extend Examples where buffer known not to be NULL: - cpv->v.b from config_plugin_values_init is not NULL if T_CONFIG_BOOL (though we might set it to NULL if buffer_is_blank(cpv->v.b)) - address of buffer is arg (&foo) (compiler optimizer detects this in most, but not all, cases) - buffer is checked for NULL earlier in func - buffer is accessed in same scope without a NULL check (e.g. b->ptr) internal behavior change: callers must not pass a NULL buffer to some funcs. - buffer_init_buffer() requires non-null args - buffer_copy_buffer() requires non-null args - buffer_append_string_buffer() requires non-null args - buffer_string_space() requires non-null arg
8 months ago
size_t olen = buffer_clen(o);
if (0 == sock_addr_nameinfo_append_buffer(o, &our_addr, r->conf.errh)) {
[multiple] reduce redundant NULL buffer checks This commit is a large set of code changes and results in removal of hundreds, perhaps thousands, of CPU instructions, a portion of which are on hot code paths. Most (buffer *) used by lighttpd are not NULL, especially since buffers were inlined into numerous larger structs such as request_st and chunk. In the small number of instances where that is not the case, a NULL check is often performed earlier in a function where that buffer is later used with a buffer_* func. In the handful of cases that remained, a NULL check was added, e.g. with r->http_host and r->conf.server_tag. - check for empty strings at config time and set value to NULL if blank string will be ignored at runtime; at runtime, simple pointer check for NULL can be used to check for a value that has been set and is not blank ("") - use buffer_is_blank() instead of buffer_string_is_empty(), and use buffer_is_unset() instead of buffer_is_empty(), where buffer is known not to be NULL so that NULL check can be skipped - use buffer_clen() instead of buffer_string_length() when buffer is known not to be NULL (to avoid NULL check at runtime) - use buffer_truncate() instead of buffer_string_set_length() to truncate string, and use buffer_extend() to extend Examples where buffer known not to be NULL: - cpv->v.b from config_plugin_values_init is not NULL if T_CONFIG_BOOL (though we might set it to NULL if buffer_is_blank(cpv->v.b)) - address of buffer is arg (&foo) (compiler optimizer detects this in most, but not all, cases) - buffer is checked for NULL earlier in func - buffer is accessed in same scope without a NULL check (e.g. b->ptr) internal behavior change: callers must not pass a NULL buffer to some funcs. - buffer_init_buffer() requires non-null args - buffer_copy_buffer() requires non-null args - buffer_append_string_buffer() requires non-null args - buffer_string_space() requires non-null arg
8 months ago
lhost_len = buffer_clen(o) - olen;
if (lhost_len < sizeof(lhost)) {
memcpy(lhost, o->ptr+olen, lhost_len+1); /*(+1 for '\0')*/
}
else {
lhost_len = 0;
}
}
else {
lhost_len = sizeof("localhost")-1;
memcpy(lhost, "localhost", lhost_len+1); /*(+1 for '\0')*/
buffer_append_string_len(o, lhost, lhost_len);
}
}
[multiple] reduce redundant NULL buffer checks This commit is a large set of code changes and results in removal of hundreds, perhaps thousands, of CPU instructions, a portion of which are on hot code paths. Most (buffer *) used by lighttpd are not NULL, especially since buffers were inlined into numerous larger structs such as request_st and chunk. In the small number of instances where that is not the case, a NULL check is often performed earlier in a function where that buffer is later used with a buffer_* func. In the handful of cases that remained, a NULL check was added, e.g. with r->http_host and r->conf.server_tag. - check for empty strings at config time and set value to NULL if blank string will be ignored at runtime; at runtime, simple pointer check for NULL can be used to check for a value that has been set and is not blank ("") - use buffer_is_blank() instead of buffer_string_is_empty(), and use buffer_is_unset() instead of buffer_is_empty(), where buffer is known not to be NULL so that NULL check can be skipped - use buffer_clen() instead of buffer_string_length() when buffer is known not to be NULL (to avoid NULL check at runtime) - use buffer_truncate() instead of buffer_string_set_length() to truncate string, and use buffer_extend() to extend Examples where buffer known not to be NULL: - cpv->v.b from config_plugin_values_init is not NULL if T_CONFIG_BOOL (though we might set it to NULL if buffer_is_blank(cpv->v.b)) - address of buffer is arg (&foo) (compiler optimizer detects this in most, but not all, cases) - buffer is checked for NULL earlier in func - buffer is accessed in same scope without a NULL check (e.g. b->ptr) internal behavior change: callers must not pass a NULL buffer to some funcs. - buffer_init_buffer() requires non-null args - buffer_copy_buffer() requires non-null args - buffer_append_string_buffer() requires non-null args - buffer_string_space() requires non-null arg
8 months ago
} else if (!buffer_is_blank(r->server_name)) {
buffer_append_string_buffer(o, r->server_name);
} else
/* Lookup name: secondly try to get hostname for bind address */
if (0 != sock_addr_nameinfo_append_buffer(o, &our_addr, r->conf.errh)) {
r->http_status = 500;
return -1;
}
{
unsigned short listen_port = sock_addr_get_port(&our_addr);
unsigned short default_port = 80;
if (buffer_is_equal_string(&r->uri.scheme, CONST_STR_LEN("https"))) {
default_port = 443;
}
if (0 == listen_port) listen_port = r->con->srv->srvconf.port;
if (default_port != listen_port) {
buffer_append_string_len(o, CONST_STR_LEN(":"));
buffer_append_int(o, listen_port);
}
}
}
return 0;
}
int http_response_redirect_to_directory(request_st * const r, int status) {
buffer *o = r->tmp_buf;
buffer_clear(o);
/* XXX: store flag in global at startup? */
if (r->con->srv->srvconf.absolute_dir_redirect) {
[multiple] reduce redundant NULL buffer checks This commit is a large set of code changes and results in removal of hundreds, perhaps thousands, of CPU instructions, a portion of which are on hot code paths. Most (buffer *) used by lighttpd are not NULL, especially since buffers were inlined into numerous larger structs such as request_st and chunk. In the small number of instances where that is not the case, a NULL check is often performed earlier in a function where that buffer is later used with a buffer_* func. In the handful of cases that remained, a NULL check was added, e.g. with r->http_host and r->conf.server_tag. - check for empty strings at config time and set value to NULL if blank string will be ignored at runtime; at runtime, simple pointer check for NULL can be used to check for a value that has been set and is not blank ("") - use buffer_is_blank() instead of buffer_string_is_empty(), and use buffer_is_unset() instead of buffer_is_empty(), where buffer is known not to be NULL so that NULL check can be skipped - use buffer_clen() instead of buffer_string_length() when buffer is known not to be NULL (to avoid NULL check at runtime) - use buffer_truncate() instead of buffer_string_set_length() to truncate string, and use buffer_extend() to extend Examples where buffer known not to be NULL: - cpv->v.b from config_plugin_values_init is not NULL if T_CONFIG_BOOL (though we might set it to NULL if buffer_is_blank(cpv->v.b)) - address of buffer is arg (&foo) (compiler optimizer detects this in most, but not all, cases) - buffer is checked for NULL earlier in func - buffer is accessed in same scope without a NULL check (e.g. b->ptr) internal behavior change: callers must not pass a NULL buffer to some funcs. - buffer_init_buffer() requires non-null args - buffer_copy_buffer() requires non-null args - buffer_append_string_buffer() requires non-null args - buffer_string_space() requires non-null arg
8 months ago
buffer_append_str2(o, BUF_PTR_LEN(&r->uri.scheme),
CONST_STR_LEN("://"));
if (0 != http_response_buffer_append_authority(r, o)) {
return -1;
}
}
buffer *vb;
if (status >= 300) {
r->http_status = status;
r->resp_body_finished = 1;
vb = http_header_response_set_ptr(r, HTTP_HEADER_LOCATION,
CONST_STR_LEN("Location"));
}
else {
vb = http_header_response_set_ptr(r, HTTP_HEADER_CONTENT_LOCATION,
CONST_STR_LEN("Content-Location"));
}
buffer_copy_buffer(vb, o);
[multiple] reduce redundant NULL buffer checks This commit is a large set of code changes and results in removal of hundreds, perhaps thousands, of CPU instructions, a portion of which are on hot code paths. Most (buffer *) used by lighttpd are not NULL, especially since buffers were inlined into numerous larger structs such as request_st and chunk. In the small number of instances where that is not the case, a NULL check is often performed earlier in a function where that buffer is later used with a buffer_* func. In the handful of cases that remained, a NULL check was added, e.g. with r->http_host and r->conf.server_tag. - check for empty strings at config time and set value to NULL if blank string will be ignored at runtime; at runtime, simple pointer check for NULL can be used to check for a value that has been set and is not blank ("") - use buffer_is_blank() instead of buffer_string_is_empty(), and use buffer_is_unset() instead of buffer_is_empty(), where buffer is known not to be NULL so that NULL check can be skipped - use buffer_clen() instead of buffer_string_length() when buffer is known not to be NULL (to avoid NULL check at runtime) - use buffer_truncate() instead of buffer_string_set_length() to truncate string, and use buffer_extend() to extend Examples where buffer known not to be NULL: - cpv->v.b from config_plugin_values_init is not NULL if T_CONFIG_BOOL (though we might set it to NULL if buffer_is_blank(cpv->v.b)) - address of buffer is arg (&foo) (compiler optimizer detects this in most, but not all, cases) - buffer is checked for NULL earlier in func - buffer is accessed in same scope without a NULL check (e.g. b->ptr) internal behavior change: callers must not pass a NULL buffer to some funcs. - buffer_init_buffer() requires non-null args - buffer_copy_buffer() requires non-null args - buffer_append_string_buffer() requires non-null args - buffer_string_space() requires non-null arg
8 months ago
buffer_append_string_encoded(vb, BUF_PTR_LEN(&r->uri.path),
ENCODING_REL_URI);
buffer_append_string_len(vb, CONST_STR_LEN("/"));
[multiple] reduce redundant NULL buffer checks This commit is a large set of code changes and results in removal of hundreds, perhaps thousands, of CPU instructions, a portion of which are on hot code paths. Most (buffer *) used by lighttpd are not NULL, especially since buffers were inlined into numerous larger structs such as request_st and chunk. In the small number of instances where that is not the case, a NULL check is often performed earlier in a function where that buffer is later used with a buffer_* func. In the handful of cases that remained, a NULL check was added, e.g. with r->http_host and r->conf.server_tag. - check for empty strings at config time and set value to NULL if blank string will be ignored at runtime; at runtime, simple pointer check for NULL can be used to check for a value that has been set and is not blank ("") - use buffer_is_blank() instead of buffer_string_is_empty(), and use buffer_is_unset() instead of buffer_is_empty(), where buffer is known not to be NULL so that NULL check can be skipped - use buffer_clen() instead of buffer_string_length() when buffer is known not to be NULL (to avoid NULL check at runtime) - use buffer_truncate() instead of buffer_string_set_length() to truncate string, and use buffer_extend() to extend Examples where buffer known not to be NULL: - cpv->v.b from config_plugin_values_init is not NULL if T_CONFIG_BOOL (though we might set it to NULL if buffer_is_blank(cpv->v.b)) - address of buffer is arg (&foo) (compiler optimizer detects this in most, but not all, cases) - buffer is checked for NULL earlier in func - buffer is accessed in same scope without a NULL check (e.g. b->ptr) internal behavior change: callers must not pass a NULL buffer to some funcs. - buffer_init_buffer() requires non-null args - buffer_copy_buffer() requires non-null args - buffer_append_string_buffer() requires non-null args - buffer_string_space() requires non-null arg
8 months ago
if (!buffer_is_blank(&r->uri.query))
buffer_append_str2(vb, CONST_STR_LEN("?"),
[multiple] reduce redundant NULL buffer checks This commit is a large set of code changes and results in removal of hundreds, perhaps thousands, of CPU instructions, a portion of which are on hot code paths. Most (buffer *) used by lighttpd are not NULL, especially since buffers were inlined into numerous larger structs such as request_st and chunk. In the small number of instances where that is not the case, a NULL check is often performed earlier in a function where that buffer is later used with a buffer_* func. In the handful of cases that remained, a NULL check was added, e.g. with r->http_host and r->conf.server_tag. - check for empty strings at config time and set value to NULL if blank string will be ignored at runtime; at runtime, simple pointer check for NULL can be used to check for a value that has been set and is not blank ("") - use buffer_is_blank() instead of buffer_string_is_empty(), and use buffer_is_unset() instead of buffer_is_empty(), where buffer is known not to be NULL so that NULL check can be skipped - use buffer_clen() instead of buffer_string_length() when buffer is known not to be NULL (to avoid NULL check at runtime) - use buffer_truncate() instead of buffer_string_set_length() to truncate string, and use buffer_extend() to extend Examples where buffer known not to be NULL: - cpv->v.b from config_plugin_values_init is not NULL if T_CONFIG_BOOL (though we might set it to NULL if buffer_is_blank(cpv->v.b)) - address of buffer is arg (&foo) (compiler optimizer detects this in most, but not all, cases) - buffer is checked for NULL earlier in func - buffer is accessed in same scope without a NULL check (e.g. b->ptr) internal behavior change: callers must not pass a NULL buffer to some funcs. - buffer_init_buffer() requires non-null args - buffer_copy_buffer() requires non-null args - buffer_append_string_buffer() requires non-null args - buffer_string_space() requires non-null arg
8 months ago
BUF_PTR_LEN(&r->uri.query));
return 0;
}
#define MTIME_CACHE_MAX 16
struct mtime_cache_type {
[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/
7 months ago
unix_time64_t mtime; /* key */
buffer str; /* buffer for string representation */
};
static struct mtime_cache_type mtime_cache[MTIME_CACHE_MAX];
static char mtime_cache_str[MTIME_CACHE_MAX][HTTP_DATE_SZ];
/* 30-chars for "%a, %d %b %Y %T GMT" */
void strftime_cache_reset(void) {
for (int i = 0; i < MTIME_CACHE_MAX; ++i) {
[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/
7 months ago
mtime_cache[i].mtime = -1;
mtime_cache[i].str.ptr = mtime_cache_str[i];
mtime_cache[i].str.used = sizeof(mtime_cache_str[0]);
mtime_cache[i].str.size = sizeof(mtime_cache_str[0]);
}
}
[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/
7 months ago
static const buffer * strftime_cache_get(const unix_time64_t last_mod) {
/*(note: not bothering to convert *here* if last_mod < 0 (for cache key);
* last_mod < 0 handled in http_date_time_to_str() call to gmtime64_r())*/
static int mtime_cache_idx;
for (int j = 0; j < MTIME_CACHE_MAX; ++j) {
if (mtime_cache[j].mtime == last_mod)
return &mtime_cache[j].str; /* found cache-entry */
}
if (++mtime_cache_idx == MTIME_CACHE_MAX) mtime_cache_idx = 0;
const int i = mtime_cache_idx;
http_date_time_to_str(mtime_cache[i].str.ptr, sizeof(mtime_cache_str[0]),
(mtime_cache[i].mtime = last_mod));
return &mtime_cache[i].str;
}
[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/
7 months ago
const buffer * http_response_set_last_modified(request_st * const r, const unix_time64_t lmtime) {
buffer * const vb =
http_header_response_set_ptr(r, HTTP_HEADER_LAST_MODIFIED,
CONST_STR_LEN("Last-Modified"));
buffer_copy_buffer(vb, strftime_cache_get(lmtime));
return vb;
}
[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/
7 months ago
int http_response_handle_cachable(request_st * const r, const buffer * const lmod, const unix_time64_t lmtime) {
if (!(r->rqst_htags
& (light_bshift(HTTP_HEADER_IF_NONE_MATCH)
|light_bshift(HTTP_HEADER_IF_MODIFIED_SINCE)))) {
return HANDLER_GO_ON;
}
const buffer *vb;
/*
* 14.26 If-None-Match
* [...]
* If none of the entity tags match, then the server MAY perform the
* requested method as if the If-None-Match header field did not exist,
* but MUST also ignore any If-Modified-Since header field(s) in the
* request. That is, if no entity tags match, then the server MUST NOT
* return a 304 (Not Modified) response.
*/
if ((vb = http_header_request_get(r, HTTP_HEADER_IF_NONE_MATCH,
CONST_STR_LEN("If-None-Match")))) {
/*(weak etag comparison must not be used for ranged requests)*/
int range_request = (0 != light_btst(r->rqst_htags, HTTP_HEADER_RANGE));
if (http_etag_matches(&r->physical.etag, vb->ptr, !range_request)) {
if (http_method_get_or_head(r->http_method)) {
r->http_status = 304;
return HANDLER_FINISHED;
} else {
r->http_status = 412;
r->handler_module = NULL;
return HANDLER_FINISHED;
}
}
} else if (http_method_get_or_head(r->http_method)
&& (vb = http_header_request_get(r, HTTP_HEADER_IF_MODIFIED_SINCE,
CONST_STR_LEN("If-Modified-Since")))) {
/* last-modified handling */
if (buffer_is_equal(lmod, vb)
[multiple] reduce redundant NULL buffer checks This commit is a large set of code changes and results in removal of hundreds, perhaps thousands, of CPU instructions, a portion of which are on hot code paths. Most (buffer *) used by lighttpd are not NULL, especially since buffers were inlined into numerous larger structs such as request_st and chunk. In the small number of instances where that is not the case, a NULL check is often performed earlier in a function where that buffer is later used with a buffer_* func. In the handful of cases that remained, a NULL check was added, e.g. with r->http_host and r->conf.server_tag. - check for empty strings at config time and set value to NULL if blank string will be ignored at runtime; at runtime, simple pointer check for NULL can be used to check for a value that has been set and is not blank ("") - use buffer_is_blank() instead of buffer_string_is_empty(), and use buffer_is_unset() instead of buffer_is_empty(), where buffer is known not to be NULL so that NULL check can be skipped - use buffer_clen() instead of buffer_string_length() when buffer is known not to be NULL (to avoid NULL check at runtime) - use buffer_truncate() instead of buffer_string_set_length() to truncate string, and use buffer_extend() to extend Examples where buffer known not to be NULL: - cpv->v.b from config_plugin_values_init is not NULL if T_CONFIG_BOOL (though we might set it to NULL if buffer_is_blank(cpv->v.b)) - address of buffer is arg (&foo) (compiler optimizer detects this in most, but not all, cases) - buffer is checked for NULL earlier in func - buffer is accessed in same scope without a NULL check (e.g. b->ptr) internal behavior change: callers must not pass a NULL buffer to some funcs. - buffer_init_buffer() requires non-null args - buffer_copy_buffer() requires non-null args - buffer_append_string_buffer() requires non-null args - buffer_string_space() requires non-null arg
8 months ago
|| !http_date_if_modified_since(BUF_PTR_LEN(vb), lmtime)) {
r->http_status = 304;
return HANDLER_FINISHED;
}
}
return HANDLER_GO_ON;
}
void http_response_body_clear (request_st * const r, int preserve_length) {
r->resp_send_chunked = 0;
r->resp_body_scratchpad = -1;
if (light_btst(r->resp_htags, HTTP_HEADER_TRANSFER_ENCODING)) {
http_header_response_unset(r, HTTP_HEADER_TRANSFER_ENCODING,
CONST_STR_LEN("Transfer-Encoding"));
}
if (!preserve_length) { /* preserve for HEAD responses and no-content responses (204, 205, 304) */
if (light_btst(r->resp_htags, HTTP_HEADER_CONTENT_LENGTH)) {
http_header_response_unset(r, HTTP_HEADER_CONTENT_LENGTH,
CONST_STR_LEN("Content-Length"));
}
/*(if not preserving Content-Length, do not preserve trailers, if any)*/
r->resp_decode_chunked = 0;
if (r->gw_dechunk) {
free(r->gw_dechunk->b.ptr);
free(r->gw_dechunk);
r->gw_dechunk = NULL;
}
}
chunkqueue_reset(&r->write_queue);
}
static void http_response_header_clear (request_st * const r) {
r->http_status = 0;
r->resp_htags = 0;
r->resp_header_len = 0;
r->resp_header_repeated = 0;
array_reset_data_strings(&r->resp_headers);
/* Note: http_response_body_clear(r, 0) is not called here
* r->write_queue should be preserved for additional data after 1xx response
* However, if http_response_process_headers() was called and response had
* Transfer-Encoding: chunked set, then other items need to be reset */
r->resp_send_chunked = 0;
r->resp_decode_chunked = 0;
r->resp_body_scratchpad = -1;
if (r->gw_dechunk) {
free(r->gw_dechunk->b.ptr);
free(r->gw_dechunk);
r->gw_dechunk = NULL;
}
}
void http_response_reset (request_st * const r) {
r->http_status = 0;
r->con->is_writable = 1;
r->resp_body_finished = 0;
r->resp_body_started = 0;
r->handler_module = NULL;
if (r->physical.path.ptr) { /*(skip for mod_fastcgi authorizer)*/
buffer_clear(&r->physical.doc_root);
buffer_clear(&r->physical.basedir);
buffer_clear(&r->physical.etag);
buffer_reset(&r->physical.path);
buffer_reset(&r->physical.rel_path);
}
r->resp_htags = 0;
r->resp_header_len = 0;
r->resp_header_repeated = 0;
array_reset_data_strings(&r->resp_headers);
http_response_body_clear(r, 0);
}
handler_t http_response_reqbody_read_error (request_st * const r, int http_status) {
r->keep_alive = 0;
/*(do not change status if response headers already set and possibly sent)*/
if (0 != r->resp_header_len) return HANDLER_ERROR;
http_response_body_clear(r, 0);
r->http_status = http_status;
r->handler_module = NULL;
return HANDLER_FINISHED;
}
void http_response_send_file (request_st * const r, buffer * const path, stat_cache_entry *sce) {
if (NULL == sce
|| (sce->fd < 0 && __builtin_expect( (0 != sce->st.st_size), 0))) {
sce = stat_cache_get_entry_open(path, r->conf.follow_symlink);
if (NULL == sce) {
r->http_status = (errno == ENOENT) ? 404 : 403;
log_error(r->conf.errh, __FILE__, __LINE__,
"not a regular file: %s -> %s", r->uri.path.ptr, path->ptr);
return;
}
if (sce->fd < 0 && __builtin_expect( (0 != sce->st.st_size), 0)) {
r->http_status = (errno == ENOENT) ? 404 : 403;
if (r->conf.log_request_handling) {
log_perror(r->conf.errh, __FILE__, __LINE__,
"file open failed: %s", path->ptr);
}
return;
}
}
if (__builtin_expect( (!r->conf.follow_symlink), 0)
&& 0 != stat_cache_path_contains_symlink(path, r->conf.errh)) {
r->http_status = 403;
if (r->conf.log_request_handling) {
log_error(r->conf.errh, __FILE__, __LINE__,
"-- access denied due symlink restriction");
log_error(r->conf.errh, __FILE__, __LINE__,
"Path : %s", path->ptr);
}
return;
}
/* we only handle regular files */
if (__builtin_expect( (!S_ISREG(sce->st.st_mode)), 0)) {
r->http_status = 403;
if (r->conf.log_file_not_found) {
log_error(r->conf.errh, __FILE__, __LINE__,
"not a regular file: %s -> %s",
r->uri.path.ptr, path->ptr);
}
return;
}
int allow_caching = (0 == r->http_status || 200 == r->http_status);
/* set response content-type, if not set already */
if (!light_btst(r->resp_htags, HTTP_HEADER_CONTENT_TYPE)) {
const buffer *content_type = stat_cache_content_type_get(sce, r);
[multiple] reduce redundant NULL buffer checks This commit is a large set of code changes and results in removal of hundreds, perhaps thousands, of CPU instructions, a portion of which are on hot code paths. Most (buffer *) used by lighttpd are not NULL, especially since buffers were inlined into numerous larger structs such as request_st and chunk. In the small number of instances where that is not the case, a NULL check is often performed earlier in a function where that buffer is later used with a buffer_* func. In the handful of cases that remained, a NULL check was added, e.g. with r->http_host and r->conf.server_tag. - check for empty strings at config time and set value to NULL if blank string will be ignored at runtime; at runtime, simple pointer check for NULL can be used to check for a value that has been set and is not blank ("") - use buffer_is_blank() instead of buffer_string_is_empty(), and use buffer_is_unset() instead of buffer_is_empty(), where buffer is known not to be NULL so that NULL check can be skipped - use buffer_clen() instead of buffer_string_length() when buffer is known not to be NULL (to avoid NULL check at runtime) - use buffer_truncate() instead of buffer_string_set_length() to truncate string, and use buffer_extend() to extend Examples where buffer known not to be NULL: - cpv->v.b from config_plugin_values_init is not NULL if T_CONFIG_BOOL (though we might set it to NULL if buffer_is_blank(cpv->v.b)) - address of buffer is arg (&foo) (compiler optimizer detects this in most, but not all, cases) - buffer is checked for NULL earlier in func - buffer is accessed in same scope without a NULL check (e.g. b->ptr) internal behavior change: callers must not pass a NULL buffer to some funcs. - buffer_init_buffer() requires non-null args - buffer_copy_buffer() requires non-null args - buffer_append_string_buffer() requires non-null args - buffer_string_space() requires non-null arg
8 months ago
if (content_type && !buffer_is_blank(content_type)) {
http_header_response_set(r, HTTP_HEADER_CONTENT_TYPE,
CONST_STR_LEN("Content-Type"),
BUF_PTR_LEN(content_type));
} else {
/* we are setting application/octet-stream, but also announce that
* this header field might change in the seconds few requests
*
* This should fix the aggressive caching of FF and the script download
* seen by the first installations
*/
http_header_response_set(r, HTTP_HEADER_CONTENT_TYPE,
CONST_STR_LEN("Content-Type"),
CONST_STR_LEN("application/octet-stream"));
allow_caching = 0;
}
}
if (allow_caching) {
if (!light_btst(r->resp_htags, HTTP_HEADER_ETAG)
&& 0 != r->conf.etag_flags) {
const buffer *etag =
stat_cache_etag_get(sce, r->conf.etag_flags);
[multiple] reduce redundant NULL buffer checks This commit is a large set of code changes and results in removal of hundreds, perhaps thousands, of CPU instructions, a portion of which are on hot code paths. Most (buffer *) used by lighttpd are not NULL, especially since buffers were inlined into numerous larger structs such as request_st and chunk. In the small number of instances where that is not the case, a NULL check is often performed earlier in a function where that buffer is later used with a buffer_* func. In the handful of cases that remained, a NULL check was added, e.g. with r->http_host and r->conf.server_tag. - check for empty strings at config time and set value to NULL if blank string will be ignored at runtime; at runtime, simple pointer check for NULL can be used to check for a value that has been set and is not blank ("") - use buffer_is_blank() instead of buffer_string_is_empty(), and use buffer_is_unset() instead of buffer_is_empty(), where buffer is known not to be NULL so that NULL check can be skipped - use buffer_clen() instead of buffer_string_length() when buffer is known not to be NULL (to avoid NULL check at runtime) - use buffer_truncate() instead of buffer_string_set_length() to truncate string, and use buffer_extend() to extend Examples where buffer known not to be NULL: - cpv->v.b from config_plugin_values_init is not NULL if T_CONFIG_BOOL (though we might set it to NULL if buffer_is_blank(cpv->v.b)) - address of buffer is arg (&foo) (compiler optimizer detects this in most, but not all, cases) - buffer is checked for NULL earlier in func - buffer is accessed in same scope without a NULL check (e.g. b->ptr) internal behavior change: callers must not pass a NULL buffer to some funcs. - buffer_init_buffer() requires non-null args - buffer_copy_buffer() requires non-null args - buffer_append_string_buffer() requires non-null args - buffer_string_space() requires non-null arg
8 months ago
if (etag && !buffer_is_blank(etag)) {
buffer_copy_buffer(&r->physical.etag, etag);
http_header_response_set(r, HTTP_HEADER_ETAG,
CONST_STR_LEN("ETag"),
[multiple] reduce redundant NULL buffer checks This commit is a large set of code changes and results in removal of hundreds, perhaps thousands, of CPU instructions, a portion of which are on hot code paths. Most (buffer *) used by lighttpd are not NULL, especially since buffers were inlined into numerous larger structs such as request_st and chunk. In the small number of instances where that is not the case, a NULL check is often performed earlier in a function where that buffer is later used with a buffer_* func. In the handful of cases that remained, a NULL check was added, e.g. with r->http_host and r->conf.server_tag. - check for empty strings at config time and set value to NULL if blank string will be ignored at runtime; at runtime, simple pointer check for NULL can be used to check for a value that has been set and is not blank ("") - use buffer_is_blank() instead of buffer_string_is_empty(), and use buffer_is_unset() instead of buffer_is_empty(), where buffer is known not to be NULL so that NULL check can be skipped - use buffer_clen() instead of buffer_string_length() when buffer is known not to be NULL (to avoid NULL check at runtime) - use buffer_truncate() instead of buffer_string_set_length() to truncate string, and use buffer_extend() to extend Examples where buffer known not to be NULL: - cpv->v.b from config_plugin_values_init is not NULL if T_CONFIG_BOOL (though we might set it to NULL if buffer_is_blank(cpv->v.b)) - address of buffer is arg (&foo) (compiler optimizer detects this in most, but not all, cases) - buffer is checked for NULL earlier in func - buffer is accessed in same scope without a NULL check (e.g. b->ptr) internal behavior change: callers must not pass a NULL buffer to some funcs. - buffer_init_buffer() requires non-null args - buffer_copy_buffer() requires non-null args - buffer_append_string_buffer() requires non-null args - buffer_string_space() requires non-null arg
8 months ago
BUF_PTR_LEN(&r->physical.etag));
}
}
/* prepare header */
const buffer *mtime;
mtime = http_header_response_get(r, HTTP_HEADER_LAST_MODIFIED,
CONST_STR_LEN("Last-Modified"));
if (NULL == mtime) {
mtime = http_response_set_last_modified(r, sce->st.st_mtime);
}
if (HANDLER_FINISHED == http_response_handle_cachable(r, mtime, sce->st.st_mtime)) {
return;
}
}
/* if we are still here, prepare body */
/* we add it here for all requests
* the HEAD request will drop it afterwards again
*/
if (0 == sce->st.st_size || 0 == http_chunk_append_file_ref(r, sce)) {
r->http_status = 200;
r->resp_body_finished = 1;
/*(Transfer-Encoding should not have been set at this point)*/
buffer_append_int(
http_header_response_set_ptr(r, HTTP_HEADER_CONTENT_LENGTH,
CONST_STR_LEN("Content-Length")),
sce->st.st_size);
}
else {
r->http_status = 500;
}
}
[mod_fastcgi] use http_response_xsendfile() (fixes #799, fixes #851, fixes #2017, fixes #2076) handle X-Sendfile and X-LIGHTTPD-send-file w/ http_response_xsendfile() if host is configured ( "x-sendfile" = "enable" ) Note: X-Sendfile path is url-decoded for consistency, like X-Sendfile2 (response headers should be url-encoded to avoid tripping over chars allowed in filesystem but which might change response header parsing semantics) Note: deprecated: "allow-x-send-file"; use "x-sendfile" Note: deprecated: X-LIGHTTPD-send-file header; use X-Sendfile header Note: deprecated: X-Sendfile2 header; use X-Sendfile header For now, X-Sendfile2 is still handled internally by mod_fastcgi. Since http_response_send_file() supports HTTP Range requests, X-Sendfile2 is effectively obsolete. However, any code, e.g. PHP, currently using X-Sendfile2 is probably manually generating 206 Partial Content status and Range response headers. A future version of lighttpd might *remove* X-Sendfile2. Existing code should be converted to use X-Sendfile, which is easily done by removing all the special logic around using X-Sendfile2, since the 206 Partial Content status and Range response headers are handled in http_response_send_file(). x-ref: "mod_fastcgi + X-Sendfile -> mod_staticfile" https://redmine.lighttpd.net/issues/799 "Feature Request: New option "x-send-file-docroot"" https://redmine.lighttpd.net/issues/851 "X-Sendfile handoff to mod-static-file in 1.4.x" https://redmine.lighttpd.net/issues/2017 "X-sendfile should be able to set content-type" https://redmine.lighttpd.net/issues/2076
6 years ago
static void http_response_xsendfile (request_st * const r, buffer * const path, const array * const xdocroot) {
const int status = r->http_status;
[mod_fastcgi] use http_response_xsendfile() (fixes #799, fixes #851, fixes #2017, fixes #2076) handle X-Sendfile and X-LIGHTTPD-send-file w/ http_response_xsendfile() if host is configured ( "x-sendfile" = "enable" ) Note: X-Sendfile path is url-decoded for consistency, like X-Sendfile2 (response headers should be url-encoded to avoid tripping over chars allowed in filesystem but which might change response header parsing semantics) Note: deprecated: "allow-x-send-file"; use "x-sendfile" Note: deprecated: X-LIGHTTPD-send-file header; use X-Sendfile header Note: deprecated: X-Sendfile2 header; use X-Sendfile header For now, X-Sendfile2 is still handled internally by mod_fastcgi. Since http_response_send_file() supports HTTP Range requests, X-Sendfile2 is effectively obsolete. However, any code, e.g. PHP, currently using X-Sendfile2 is probably manually generating 206 Partial Content status and Range response headers. A future version of lighttpd might *remove* X-Sendfile2. Existing code should be converted to use X-Sendfile, which is easily done by removing all the special logic around using X-Sendfile2, since the 206 Partial Content status and Range response headers are handled in http_response_send_file(). x-ref: "mod_fastcgi + X-Sendfile -> mod_staticfile" https://redmine.lighttpd.net/issues/799 "Feature Request: New option "x-send-file-docroot"" https://redmine.lighttpd.net/issues/851 "X-Sendfile handoff to mod-static-file in 1.4.x" https://redmine.lighttpd.net/issues/2017 "X-sendfile should be able to set content-type" https://redmine.lighttpd.net/issues/2076
6 years ago
int valid = 1;
/* reset Content-Length, if set by backend
* Content-Length might later be set to size of X-Sendfile static file,
* determined by open(), fstat() to reduces race conditions if the file
* is modified between stat() (stat_cache_get_entry()) and open(). */
if (light_btst(r->resp_htags, HTTP_HEADER_CONTENT_LENGTH)) {
http_header_response_unset(r, HTTP_HEADER_CONTENT_LENGTH,
CONST_STR_LEN("Content-Length"));
[mod_fastcgi] use http_response_xsendfile() (fixes #799, fixes #851, fixes #2017, fixes #2076) handle X-Sendfile and X-LIGHTTPD-send-file w/ http_response_xsendfile() if host is configured ( "x-sendfile" = "enable" ) Note: X-Sendfile path is url-decoded for consistency, like X-Sendfile2 (response headers should be url-encoded to avoid tripping over chars allowed in filesystem but which might change response header parsing semantics) Note: deprecated: "allow-x-send-file"; use "x-sendfile" Note: deprecated: X-LIGHTTPD-send-file header; use X-Sendfile header Note: deprecated: X-Sendfile2 header; use X-Sendfile header For now, X-Sendfile2 is still handled internally by mod_fastcgi. Since http_response_send_file() supports HTTP Range requests, X-Sendfile2 is effectively obsolete. However, any code, e.g. PHP, currently using X-Sendfile2 is probably manually generating 206 Partial Content status and Range response headers. A future version of lighttpd might *remove* X-Sendfile2. Existing code should be converted to use X-Sendfile, which is easily done by removing all the special logic around using X-Sendfile2, since the 206 Partial Content status and Range response headers are handled in http_response_send_file(). x-ref: "mod_fastcgi + X-Sendfile -> mod_staticfile" https://redmine.lighttpd.net/issues/799 "Feature Request: New option "x-send-file-docroot"" https://redmine.lighttpd.net/issues/851 "X-Sendfile handoff to mod-static-file in 1.4.x" https://redmine.lighttpd.net/issues/2017 "X-sendfile should be able to set content-type" https://redmine.lighttpd.net/issues/2076
6 years ago
}
buffer_urldecode_path(path);
if (!buffer_is_valid_UTF8(path)) {
log_error(r->conf.errh, __FILE__, __LINE__,
"X-Sendfile invalid UTF-8 after url-decode: %s", path->ptr);
if (r->http_status < 400) {
r->http_status = 502;
r->handler_module = NULL;
}
return;
}
buffer_path_simplify(path);
if (r->conf.force_lowercase_filenames) {
[mod_fastcgi] use http_response_xsendfile() (fixes #799, fixes #851, fixes #2017, fixes #2076) handle X-Sendfile and X-LIGHTTPD-send-file w/ http_response_xsendfile() if host is configured ( "x-sendfile" = "enable" ) Note: X-Sendfile path is url-decoded for consistency, like X-Sendfile2 (response headers should be url-encoded to avoid tripping over chars allowed in filesystem but which might change response header parsing semantics) Note: deprecated: "allow-x-send-file"; use "x-sendfile" Note: deprecated: X-LIGHTTPD-send-file header; use X-Sendfile header Note: deprecated: X-Sendfile2 header; use X-Sendfile header For now, X-Sendfile2 is still handled internally by mod_fastcgi. Since http_response_send_file() supports HTTP Range requests, X-Sendfile2 is effectively obsolete. However, any code, e.g. PHP, currently using X-Sendfile2 is probably manually generating 206 Partial Content status and Range response headers. A future version of lighttpd might *remove* X-Sendfile2. Existing code should be converted to use X-Sendfile, which is easily done by removing all the special logic around using X-Sendfile2, since the 206 Partial Content status and Range response headers are handled in http_response_send_file(). x-ref: "mod_fastcgi + X-Sendfile -> mod_staticfile" https://redmine.lighttpd.net/issues/799 "Feature Request: New option "x-send-file-docroot"" https://redmine.lighttpd.net/issues/851 "X-Sendfile handoff to mod-static-file in 1.4.x" https://redmine.lighttpd.net/issues/2017 "X-sendfile should be able to set content-type" https://redmine.lighttpd.net/issues/2076
6 years ago
buffer_to_lower(path);
}
[multiple] reduce redundant NULL buffer checks This commit is a large set of code changes and results in removal of hundreds, perhaps thousands, of CPU instructions, a portion of which are on hot code paths. Most (buffer *) used by lighttpd are not NULL, especially since buffers were inlined into numerous larger structs such as request_st and chunk. In the small number of instances where that is not the case, a NULL check is often performed earlier in a function where that buffer is later used with a buffer_* func. In the handful of cases that remained, a NULL check was added, e.g. with r->http_host and r->conf.server_tag. - check for empty strings at config time and set value to NULL if blank string will be ignored at runtime; at runtime, simple pointer check for NULL can be used to check for a value that has been set and is not blank ("") - use buffer_is_blank() instead of buffer_string_is_empty(), and use buffer_is_unset() instead of buffer_is_empty(), where buffer is known not to be NULL so that NULL check can be skipped - use buffer_clen() instead of buffer_string_length() when buffer is known not to be NULL (to avoid NULL check at runtime) - use buffer_truncate() instead of buffer_string_set_length() to truncate string, and use buffer_extend() to extend Examples where buffer known not to be NULL: - cpv->v.b from config_plugin_values_init is not NULL if T_CONFIG_BOOL (though we might set it to NULL if buffer_is_blank(cpv->v.b)) - address of buffer is arg (&foo) (compiler optimizer detects this in most, but not all, cases) - buffer is checked for NULL earlier in func - buffer is accessed in same scope without a NULL check (e.g. b->ptr) internal behavior change: callers must not pass a NULL buffer to some funcs. - buffer_init_buffer() requires non-null args - buffer_copy_buffer() requires non-null args - buffer_append_string_buffer() requires non-null args - buffer_string_space() requires non-null arg
8 months ago
if (buffer_is_blank(path)) {
r->http_status = 502;
valid = 0;
}
[mod_fastcgi] use http_response_xsendfile() (fixes #799, fixes #851, fixes #2017, fixes #2076) handle X-Sendfile and X-LIGHTTPD-send-file w/ http_response_xsendfile() if host is configured ( "x-sendfile" = "enable" ) Note: X-Sendfile path is url-decoded for consistency, like X-Sendfile2 (response headers should be url-encoded to avoid tripping over chars allowed in filesystem but which might change response header parsing semantics) Note: deprecated: "allow-x-send-file"; use "x-sendfile" Note: deprecated: X-LIGHTTPD-send-file header; use X-Sendfile header Note: deprecated: X-Sendfile2 header; use X-Sendfile header For now, X-Sendfile2 is still handled internally by mod_fastcgi. Since http_response_send_file() supports HTTP Range requests, X-Sendfile2 is effectively obsolete. However, any code, e.g. PHP, currently using X-Sendfile2 is probably manually generating 206 Partial Content status and Range response headers. A future version of lighttpd might *remove* X-Sendfile2. Existing code should be converted to use X-Sendfile, which is easily done by removing all the special logic around using X-Sendfile2, since the 206 Partial Content status and Range response headers are handled in http_response_send_file(). x-ref: "mod_fastcgi + X-Sendfile -> mod_staticfile" https://redmine.lighttpd.net/issues/799 "Feature Request: New option "x-send-file-docroot"" https://redmine.lighttpd.net/issues/851 "X-Sendfile handoff to mod-static-file in 1.4.x" https://redmine.lighttpd.net/issues/2017 "X-sendfile should be able to set content-type" https://redmine.lighttpd.net/issues/2076
6 years ago
/* check that path is under xdocroot(s)
* - xdocroot should have trailing slash appended at config time
* - r->conf.force_lowercase_filenames is not a server-wide setting,
[mod_fastcgi] use http_response_xsendfile() (fixes #799, fixes #851, fixes #2017, fixes #2076) handle X-Sendfile and X-LIGHTTPD-send-file w/ http_response_xsendfile() if host is configured ( "x-sendfile" = "enable" ) Note: X-Sendfile path is url-decoded for consistency, like X-Sendfile2 (response headers should be url-encoded to avoid tripping over chars allowed in filesystem but which might change response header parsing semantics) Note: deprecated: "allow-x-send-file"; use "x-sendfile" Note: deprecated: X-LIGHTTPD-send-file header; use X-Sendfile header Note: deprecated: X-Sendfile2 header; use X-Sendfile header For now, X-Sendfile2 is still handled internally by mod_fastcgi. Since http_response_send_file() supports HTTP Range requests, X-Sendfile2 is effectively obsolete. However, any code, e.g. PHP, currently using X-Sendfile2 is probably manually generating 206 Partial Content status and Range response headers. A future version of lighttpd might *remove* X-Sendfile2. Existing code should be converted to use X-Sendfile, which is easily done by removing all the special logic around using X-Sendfile2, since the 206 Partial Content status and Range response headers are handled in http_response_send_file(). x-ref: "mod_fastcgi + X-Sendfile -> mod_staticfile" https://redmine.lighttpd.net/issues/799 "Feature Request: New option "x-send-file-docroot"" https://redmine.lighttpd.net/issues/851 "X-Sendfile handoff to mod-static-file in 1.4.x" https://redmine.lighttpd.net/issues/2017 "X-sendfile should be able to set content-type" https://redmine.lighttpd.net/issues/2076
6 years ago
* and so can not be definitively applied to xdocroot at config time*/
if (xdocroot && xdocroot->used) {
const buffer * const xval = !r->conf.force_lowercase_filenames
? array_match_value_prefix(xdocroot, path)
: array_match_value_prefix_nc(xdocroot, path);
if (NULL == xval) {
log_error(r->conf.errh, __FILE__, __LINE__,
"X-Sendfile (%s) not under configured x-sendfile-docroot(s)", path->ptr);
r->http_status = 403;
[mod_fastcgi] use http_response_xsendfile() (fixes #799, fixes #851, fixes #2017, fixes #2076) handle X-Sendfile and X-LIGHTTPD-send-file w/ http_response_xsendfile() if host is configured ( "x-sendfile" = "enable" ) Note: X-Sendfile path is url-decoded for consistency, like X-Sendfile2 (response headers should be url-encoded to avoid tripping over chars allowed in filesystem but which might change response header parsing semantics) Note: deprecated: "allow-x-send-file"; use "x-sendfile" Note: deprecated: X-LIGHTTPD-send-file header; use X-Sendfile header Note: deprecated: X-Sendfile2 header; use X-Sendfile header For now, X-Sendfile2 is still handled internally by mod_fastcgi. Since http_response_send_file() supports HTTP Range requests, X-Sendfile2 is effectively obsolete. However, any code, e.g. PHP, currently using X-Sendfile2 is probably manually generating 206 Partial Content status and Range response headers. A future version of lighttpd might *remove* X-Sendfile2. Existing code should be converted to use X-Sendfile, which is easily done by removing all the special logic around using X-Sendfile2, since the 206 Partial Content status and Range response headers are handled in http_response_send_file(). x-ref: "mod_fastcgi + X-Sendfile -> mod_staticfile" https://redmine.lighttpd.net/issues/799 "Feature Request: New option "x-send-file-docroot"" https://redmine.lighttpd.net/issues/851 "X-Sendfile handoff to mod-static-file in 1.4.x" https://redmine.lighttpd.net/issues/2017 "X-sendfile should be able to set content-type" https://redmine.lighttpd.net/issues/2076
6 years ago
valid = 0;
}
}
if (valid) http_response_send_file(r, path, NULL);
[mod_fastcgi] use http_response_xsendfile() (fixes #799, fixes #851, fixes #2017, fixes #2076) handle X-Sendfile and X-LIGHTTPD-send-file w/ http_response_xsendfile() if host is configured ( "x-sendfile" = "enable" ) Note: X-Sendfile path is url-decoded for consistency, like X-Sendfile2 (response headers should be url-encoded to avoid tripping over chars allowed in filesystem but which might change response header parsing semantics) Note: deprecated: "allow-x-send-file"; use "x-sendfile" Note: deprecated: X-LIGHTTPD-send-file header; use X-Sendfile header Note: deprecated: X-Sendfile2 header; use X-Sendfile header For now, X-Sendfile2 is still handled internally by mod_fastcgi. Since http_response_send_file() supports HTTP Range requests, X-Sendfile2 is effectively obsolete. However, any code, e.g. PHP, currently using X-Sendfile2 is probably manually generating 206 Partial Content status and Range response headers. A future version of lighttpd might *remove* X-Sendfile2. Existing code should be converted to use X-Sendfile, which is easily done by removing all the special logic around using X-Sendfile2, since the 206 Partial Content status and Range response headers are handled in http_response_send_file(). x-ref: "mod_fastcgi + X-Sendfile -> mod_staticfile" https://redmine.lighttpd.net/issues/799 "Feature Request: New option "x-send-file-docroot"" https://redmine.lighttpd.net/issues/851 "X-Sendfile handoff to mod-static-file in 1.4.x" https://redmine.lighttpd.net/issues/2017 "X-sendfile should be able to set content-type" https://redmine.lighttpd.net/issues/2076
6 years ago
if (r->http_status >= 400 && status < 300) {
r->handler_module = NULL;
[mod_fastcgi] use http_response_xsendfile() (fixes #799, fixes #851, fixes #2017, fixes #2076) handle X-Sendfile and X-LIGHTTPD-send-file w/ http_response_xsendfile() if host is configured ( "x-sendfile" = "enable" ) Note: X-Sendfile path is url-decoded for consistency, like X-Sendfile2 (response headers should be url-encoded to avoid tripping over chars allowed in filesystem but which might change response header parsing semantics) Note: deprecated: "allow-x-send-file"; use "x-sendfile" Note: deprecated: X-LIGHTTPD-send-file header; use X-Sendfile header Note: deprecated: X-Sendfile2 header; use X-Sendfile header For now, X-Sendfile2 is still handled internally by mod_fastcgi. Since http_response_send_file() supports HTTP Range requests, X-Sendfile2 is effectively obsolete. However, any code, e.g. PHP, currently using X-Sendfile2 is probably manually generating 206 Partial Content status and Range response headers. A future version of lighttpd might *remove* X-Sendfile2. Existing code should be converted to use X-Sendfile, which is easily done by removing all the special logic around using X-Sendfile2, since the 206 Partial Content status and Range response headers are handled in http_response_send_file(). x-ref: "mod_fastcgi + X-Sendfile -> mod_staticfile" https://redmine.lighttpd.net/issues/799 "Feature Request: New option "x-send-file-docroot"" https://redmine.lighttpd.net/issues/851 "X-Sendfile handoff to mod-static-file in 1.4.x" https://redmine.lighttpd.net/issues/2017 "X-sendfile should be able to set content-type" https://redmine.lighttpd.net/issues/2076
6 years ago
} else if (0 != status && 200 != status) {
r->http_status = status;
[mod_fastcgi] use http_response_xsendfile() (fixes #799, fixes #851, fixes #2017, fixes #2076) handle X-Sendfile and X-LIGHTTPD-send-file w/ http_response_xsendfile() if host is configured ( "x-sendfile" = "enable" ) Note: X-Sendfile path is url-decoded for consistency, like X-Sendfile2 (response headers should be url-encoded to avoid tripping over chars allowed in filesystem but which might change response header parsing semantics) Note: deprecated: "allow-x-send-file"; use "x-sendfile" Note: deprecated: X-LIGHTTPD-send-file header; use X-Sendfile header Note: deprecated: X-Sendfile2 header; use X-Sendfile header For now, X-Sendfile2 is still handled internally by mod_fastcgi. Since http_response_send_file() supports HTTP Range requests, X-Sendfile2 is effectively obsolete. However, any code, e.g. PHP, currently using X-Sendfile2 is probably manually generating 206 Partial Content status and Range response headers. A future version of lighttpd might *remove* X-Sendfile2. Existing code should be converted to use X-Sendfile, which is easily done by removing all the special logic around using X-Sendfile2, since the 206 Partial Content status and Range response headers are handled in http_response_send_file(). x-ref: "mod_fastcgi + X-Sendfile -> mod_staticfile" https://redmine.lighttpd.net/issues/799 "Feature Request: New option "x-send-file-docroot"" https://redmine.lighttpd.net/issues/851 "X-Sendfile handoff to mod-static-file in 1.4.x" https://redmine.lighttpd.net/issues/2017 "X-sendfile should be able to set content-type" https://redmine.lighttpd.net/issues/2076
6 years ago
}
}
static void http_response_xsendfile2(request_st * const r, const buffer * const value, const array * const xdocroot) {
const char *pos = value->ptr;
buffer * const b = r->tmp_buf;
const int status = r->http_status;
/* reset Content-Length, if set by backend */
if (light_btst(r->resp_htags, HTTP_HEADER_CONTENT_LENGTH)) {
http_header_response_unset(r, HTTP_HEADER_CONTENT_LENGTH,
CONST_STR_LEN("Content-Length"));
}
while (*pos) {
const char *filename, *range;
stat_cache_entry *sce;
off_t begin_range, end_range, range_len;
while (' ' == *pos) pos++;
if (!*pos) break;
filename = pos;
if (NULL == (range = strchr(pos, ' '))) {
/* missing range */
log_error(r->conf.errh, __FILE__, __LINE__,
"Couldn't find range after filename: %s", filename);
r->http_status = 502;
break;
}
buffer_copy_string_len(b, filename, range - filename);
/* find end of range */
for (pos = ++range; *pos && *pos != ' ' && *pos != ','; pos++) ;
buffer_urldecode_path(b);