The size of the priority field is increased by one bit in spdy/3, and now it's a 3-bit field followed by 5 bits of unused space. But a shift of these bits hasn't been adjusted in 39d7eef2e332 accordingly.
Newer gcc versions (4.7+) report possible use of uninitialized variable if nginx is being compiled with -O3.
On systems with OpenSSL that has NPN support but lacks ALPN support, some compilers emitted a warning about possibly uninitialized "data" variable.
If "proxy_pass" is specified with variables, the resulting hostname is looked up in the list of upstreams defined in configuration. The search was case-sensitive, as opposed to the case of "proxy_pass" specified without variables.
Signed-off-by: Piotr Sikora <piotr@cloudflare.com>
If seek position is within the last track chunk and that chunk is standalone (stsc entry describes only this chunk) such seek generates stsc seek error. The problem is that chunk numbers start with 1, not with 0.
Mp4 module does not check movie and track durations when reading file. Instead it generates errors when track metadata is shorter than seek position. Now such tracks are skipped and movie duration check is performed at file read stage.
Mp4 module does not allow seeks after the last key frame. Since stss atom only contains key frames it's usually shorter than other track atoms. That leads to stss seek error when seek position is close to the end of file. The fix outputs empty stss frame instead of generating error.
Backed out 05a56ebb084a, as it turns out that kernel can return connections without any delay if syncookies are used. This basically means we can't assume anything about connections returned with deferred accept set. To solve original problem the 05a56ebb084a tried to solve, i.e. to don't wait longer than needed if a connection was accepted after deferred accept timeout, this patch changes a timeout set with setsockopt(TCP_DEFER_ACCEPT) to 1 second, unconditionally. This is believed to be enough for speed improvements, and doesn't imply major changes to timeouts used. Note that before 2.6.32 connections were dropped after a timeout. Though it is believed that 1s is still appropriate for kernels before 2.6.32, as previously tcp_synack_retries controlled the actual timeout and 1s results in more than 1 minute actual timeout by default.