Specifically, it is now allowed to start with a variable expression with braces:
${name}. The opening curly bracket in such a token was previously considered
the start of a new block. Variables located anywhere else in a token worked
fine: foo${name}.
Previously, capset(2) was called with the 64-bit capabilities version _LINUX_CAPABILITY_VERSION_3. With this version Linux kernel expected two copies of struct __user_cap_data_struct, while only one was submitted. As a result, random stack memory was accessed and random capabilities were requested by the worker. This sometimes caused capset() errors. Now the 32-bit version _LINUX_CAPABILITY_VERSION_1 is used instead. This is OK since CAP_NET_RAW is a 32-bit capability (CAP_NET_RAW = 13).
Previously included file sys/capability.h mentioned in capset(2) man page, belongs to the libcap-dev package, which may not be installed on some Linux systems when compiling nginx. This prevented the capabilities feature from being detected and compiled on that systems. Now linux/capability.h system header is included instead. Since capset() declaration is located in sys/capability.h, now capset() syscall is defined explicitly in code using the SYS_capset constant, similarly to other Linux-specific features in nginx.
The capability is retained automatically in unprivileged worker processes after changing UID if transparent proxying is enabled at least once in nginx configuration. The feature is only available in Linux.
Determine cacheline size at runtime if supported using sysconf(_SC_LEVEL1_DCACHE_LINESIZE). In case not supported, fallback to compile time defaults.
If the flag space_in_uri is set, the URI in HTTP upstream request is escaped to convert space to %20. However this flag is not checked while creating the default cache key. This leads to different cache keys for requests '/foo bar' and '/foo%20bar', while the upstream requests are identical. Additionally, the change fixes background cache updates when the client URI contains unescaped space. Default cache key in a subrequest is always based on escaped URI, while the main request may not escape it. As a result, background cache update subrequest may update a different cache entry.
Inheriting this flag will make the cloned subrequest behave consistently with the parent. Specifically, the upstream HTTP request and cache key created by the proxy module may depend directly on unparsed_uri if valid_unparsed_uri flag is set. Previously, the flag was zero for cloned requests, which could make background update proxy a request different than its parent and cache the result with a different key. For example, if client URI contained the escaped slash character %2F, it was used as is by the proxy module in the main request, but was unescaped in the subrequests. Similar problems exist in the slice module.
Previously, the unparsed uri was explicitly allowed to be used only by the main request. However the valid_unparsed_uri flag is nonzero only in the main request, which makes the main request check pointless.
If the data to write is bigger than what the socket can send, and the reminder is smaller than NGX_SSL_BUFSIZE, then SSL_write() fails with SSL_ERROR_WANT_WRITE. The reminder of payload however is successfully copied to the low-level buffer and all the output chain buffers are flushed. This means that retry logic doesn't work because ngx_http_upstream_process_non_buffered_request() checks only if there's anything in the output chain buffers and ignores the fact that something may be buffered in low-level parts of the stack. Signed-off-by: Patryk Lesiewicz <patryk@google.com>
If a connection with the read delayed flag set was stored in the keepalive cache, and after picking it from the cache a read timer was set on that connection, this timer was considered a delay timer rather than a socket read event timer as expected. The latter timeout is usually much longer than the former, which caused a significant delay in request processing. The issue manifested itself with proxy_limit_rate and upstream keepalive enabled and exists since 973ee2276300 (1.7.7) when proxy_limit_rate was introduced.