The ev->timedout flag is set on first timer expiration, and never reset after it. Due to this the code to stop the timer when the timer was canceled never worked (except in a very specific time frame immediately after start), and the timer was always armed again. This essentially resulted in a buffer flush at the end of an event loop iteration. This behaviour actually seems to be better than just stopping the flush timer for the whole shutdown, so it is preserved as is instead of fixing the code to actually remove the timer. It will be further improved by upcoming changes to preserve cancelable timers if there are other timers blocking shutdown.
Previously, slice subrequest location was selected based on request URI. If request is then redirected to a new location, its context array is cleared, making the slice module loose current slice range information. This lead to broken output. Now subrequests with the NGX_HTTP_SUBREQUEST_CLONE flag are created for slices. Such subrequests stay in the same location as the parent request and keep the right slice context.
The directives enable cache updates in subrequests.
Most notably, warning W8012 (comparing signed and unsigned values) reported in multiple places where an unsigned value of small type (e.g., u_short) is promoted to an int and compared to an unsigned value. Warning W8072 (suspicious pointer arithmetic) disabled, it is reported when we increment base pointer in ngx_shm_alloc().
Relative redirects did not work with directory redirects and auto redirects issued by nginx.
By default, "map" creates cacheable variables [1]. With this parameter it creates a non-cacheable variable. An original idea was to deduce the cacheability of the "map" variable by checking the cacheability of variables specified in source and resulting values, but it turned to be too hard. For example, a cacheable variable can be overridden with the "set" directive or with the SSI "set" command. Also, keeping "map" variables cacheable by default is good for performance reasons. This required adding a new parameter. [1] Before db699978a33f (1.11.0), the cacheability of the "map" variable could vary depending on the cacheability of variables specified in resulting values (ticket #1090). This is believed to be a bug rather than a feature.