Previously, unix sockets were treated as AF_INET ones, and this may result in buffer overread on Linux, where unbound unix sockets have 2-byte addresses. Note that it is not correct to use just sun_path as a binary representation for unix sockets. This will result in an empty string for unbound unix sockets, and thus behaviour of limit_req and limit_conn will change when switching from $remote_addr to $binary_remote_addr. As such, normal text representation is used. Reported by Stephan Dollberg.
At least FreeBSD, macOS, NetBSD, and OpenBSD can return unix sockets with non-null-terminated sun_path. Additionally, the address may become non-null-terminated if it does not fit into the buffer provided and was truncated (may happen on macOS, NetBSD, and Solaris, which allow unix socket addresess larger than struct sockaddr_un). As such, ngx_sock_ntop() might overread the sockaddr provided, as it used "%s" format and thus assumed null-terminated string. To fix this, the ngx_strnlen() function was introduced, and it is now used to calculate correct length of sun_path.
Some OSes (notably macOS, NetBSD, and Solaris) allow unix socket addresses larger than struct sockaddr_un. Moreover, some of them (macOS, Solaris) return socklen of the socket address before it was truncated to fit the buffer provided. As such, on these systems socklen must not be used without additional check that it is within the buffer provided. Appropriate checks added to ngx_event_accept() (after accept()), ngx_event_recvmsg() (after recvmsg()), and ngx_set_inherited_sockets() (after getsockname()). We also obtain socket addresses via getsockname() in ngx_connection_local_sockaddr(), but it does not need any checks as it is only used for INET and INET6 sockets (as there can be no wildcard unix sockets).
The sync flag of HTTP/2 request body buffer is used when the size of request body is unknown or bigger than configured "client_body_buffer_size". In this case the buffer points to body data inside the global receive buffer that is used for reading all HTTP/2 connections in the worker process. Thus, when the sync flag is set, the buffer must be flushed to a temporary file, otherwise the request body data can be overwritten. Previously, the sync buffer wasn't flushed to a temporary file if the whole body was received in one DATA frame with the END_STREAM flag and wasn't copied into the HTTP/2 body preread buffer. As a result, the request body might be corrupted (ticket #1384). Now, setting r->request_body_in_file_only enforces writing the sync buffer to a temporary file in all cases.
When switching to a next upstream, some buffers could be stuck in the middle of the filter chain. A condition existed that raised an error when this happened. As it turned out, this condition prevented switching to a next upstream if ssl preread was used with the TCP protocol (see the ticket). In fact, the condition does not make sense for TCP, since after successful connection to an upstream switching to another upstream never happens. As for UDP, the issue with stuck buffers is unlikely to happen, but is still possible. Specifically, if a filter delays sending data to upstream. The condition can be relaxed to only check the "buffered" bitmask of the upstream connection. The new condition is simpler and fixes the ticket issue as well. Additionally, the upstream_out chain is now reset for UDP prior to connecting to a new upstream to prevent repeating the client data twice.
Total length of a response with multiple ranges can be larger than a size_t variable can hold, so type changed to off_t. Previously, an incorrect Content-Length was returned when requesting more than 4G of ranges from a large enough file on a 32-bit system. An additional size_t variable introduced to calculate size of the boundary header buffer, as off_t is not needed here and will require type casts on win32. Reported by Shuxin Yang, http://mailman.nginx.org/pipermail/nginx/2017-July/054384.html.