Previously, only one client packet could be processed in a udp stream session even though multiple response packets were supported. Now multiple packets coming from the same client address and port are delivered to the same stream session. If it's required to maintain a single stream of data, nginx should be configured in a way that all packets from a client are delivered to the same worker. On Linux and DragonFly BSD the "reuseport" parameter should be specified for this. Other systems do not currently provide appropriate mechanisms. For these systems a single stream of udp packets is only guaranteed in single-worker configurations. The proxy_response directive now specifies how many packets are expected in response to a single client packet.
Previously, ngx_event_recvmsg() got remote socket addresses after creating the connection object. In preparation to handling multiple UDP packets in a single session, this code was moved up.
On Linux recvmsg() syscall may return a zero-length client address when receiving a datagram from an unbound unix datagram socket. It is usually assumed that socket address has at least the sa_family member. Zero-length socket address caused buffer over-read in functions which receive socket address, for example ngx_sock_ntop(). Typically the over-read resulted in unexpected socket family followed by session close. Now a fake socket address is allocated instead of a zero-length client address.
On some platforms (for example, Linux with glibc 2.12-2.25) IPv4 transparent proxying is available, but IPv6 transparent proxying is not. The entire feature is enabled in this case and NGX_HAVE_TRANSPARENT_PROXY macro is set to 1. Previously, an attempt to enable transparency for an IPv6 socket was silently ignored in this case and was usually followed by a bind(2) EADDRNOTAVAIL error (ticket #1487). Now the error is generated for unavailable IPv6 transparent proxy.
In macOS 10.12, CLOCK_REALTIME and clockid_t were added, but not timer_t.
This header carries the definition of HMAC_Init_ex(). In OpenSSL this header is included by <openssl/ssl.h>, but it's not so in BoringSSL. It's probably a good idea to explicitly include this header anyway, regardless of whether it's included by other headers or not.
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 $ssl_server_name variable used SSL_get_servername() result directly, but this is not safe: it references a memory allocation in an SSL session, and this memory might be freed at any time due to renegotiation. Instead, copy the name to memory allocated from the pool.
This variable contains URL-encoded client SSL certificate. In contrast to $ssl_client_cert, it doesn't depend on deprecated header continuation. The NGX_ESCAPE_URI_COMPONENT variant of encoding is used, so the resulting variable can be safely used not only in headers, but also as a request argument. The $ssl_client_cert variable should be considered deprecated now. The $ssl_client_raw_cert variable will be eventually renambed back to $ssl_client_cert.