Since an output buffer can only be used for either reading or sending, small
amounts of data left from the previous operation (due to some limits) must be
sent before nginx will be able to read further into the buffer.  Using only
one output buffer can result in suboptimal behavior that manifests itself in
forming and sending too small chunks of data.  This is particularly painful
with SPDY (or HTTP/2) where each such chunk needs to be prefixed with some
header.

The default flow-control window in HTTP/2 is 64k minus one bytes.  With one
32k output buffer this results is one byte left after exhausting the window.
With two 32k buffers the data will be read into the second free buffer before
sending, thus the minimum output is increased to 32k + 1 bytes which is much
better.

It appears that the CONTINUATION frames don't need to be aligned to bounds of
individual headers.

If sub_filter directive was only specified at http{} level, sub filter
internal data remained uninitialized.  That would lead to a crash in runtime.

The SPDY support is removed, as it's incompatible with the new module.

A configuration like

    server { server_name .foo^@; }
    server { server_name .foo; }

resulted in a segmentation fault during construction of server names hash.

Reported by Markus Linnala.
Found with afl-fuzz.

A configuration with a named location inside a zero-length prefix
or regex location used to trigger a segmentation fault, as
ngx_http_core_location() failed to properly detect if a nested location
was created.  Example configuration to reproduce the problem:

    location "" {
        location @foo {}
    }

Fix is to not rely on a parent location name length, but rather check
command type we are currently parsing.

Identical fix is also applied to ngx_http_rewrite_if(), which used to
incorrectly assume the "if" directive is on server{} level in such
locations.

Reported by Markus Linnala.
Found with afl-fuzz.

This prevents a potential attack that discloses cached data if an attacker
will be able to craft a hash collision between some cache key the attacker
is allowed to access and another cache key with protected data.

See http://mailman.nginx.org/pipermail/nginx-devel/2015-September/007288.html.

Thanks to Gena Makhomed and Sergey Brester.