nginx.git, branch release-1.13.2

nginx-1.13.2-RELEASE

2017-06-27T14:44:17+00:00

Range filter: allowed ranges on empty files (ticket #1031).

2017-06-26T21:53:46+00:00

As per RFC 2616 / RFC 7233, any range request to an empty file
is expected to result in 416 Range Not Satisfiable response, as
there cannot be a "byte-range-spec whose first-byte-pos is less
than the current length of the entity-body".  On the other hand,
this makes use of byte-range requests inconvenient in some cases,
as reported for the slice module here:

http://mailman.nginx.org/pipermail/nginx-devel/2017-June/010177.html

This commit changes range filter to instead return 200 if the file
is empty and the range requested starts at 0.

Upstream: introduced ngx_http_upstream_ssl_handshake_handler().

2017-06-22T18:09:06+00:00

This change reworks 13a5f4765887 to only run posted requests once,
with nothing on stack.  Running posted requests with other request
functions on stack may result in use-after-free in case of errors,
similar to the one reported in #788.

To only run posted request once, a separate function was introduced
to be used as ssl handshake handler in c->ssl->handler,
ngx_http_upstream_ssl_handshake_handler().  The ngx_http_run_posted_requests()
is only called in this function, and not in ngx_http_upstream_ssl_handshake()
which may be called directly on stack.

Additionaly, ngx_http_upstream_ssl_handshake_handler() now does appropriate
debug logging of the current subrequest, similar to what is done in other
event handlers.

Upstream: fixed running posted requests (ticket #788).

2017-06-14T17:13:41+00:00

Previously, the upstream resolve handler always called
ngx_http_run_posted_requests() to run posted requests after processing the
resolver response.  However, if the handler was called directly from the
ngx_resolve_name() function (for example, if the resolver response was cached),
running posted requests from the handler could lead to the following errors:

- If the request was scheduled for termination, it could actually be terminated
in the resolve handler.  Upper stack frames could reference the freed request
object in this case.

- If a significant number of requests were posted, and for each of them the
resolve handler was called directly from the ngx_resolve_name() function,
posted requests could be run recursively and lead to stack overflow.

Now ngx_http_run_posted_requests() is only called from asynchronously invoked
resolve handlers.

Resolver: added the "async" flag to resolver context.

2017-06-14T15:13:31+00:00

The flag indicates that the resolve handler is called asynchronously after the
resolve function ngx_resolve_name()/ngx_resolve_addr() exited.

Resolver: fixed allocation error handling while resolving SRV.

2017-06-19T11:25:42+00:00

Introduced ngx_rwlock_downgrade().

2017-06-16T15:15:58+00:00

Added memory barrier semantics to ngx_rwlock_unlock().

2017-06-16T15:15:53+00:00

Headers filter: added "add_trailer" directive.

2017-03-24T10:37:34+00:00

Trailers added using this directive are evaluated after response body
is processed by output filters (but before it's written to the wire),
so it's possible to use variables calculated from the response body
as the trailer value.

Signed-off-by: Piotr Sikora

HTTP/2: added support for trailers in HTTP responses.

2017-03-24T10:37:34+00:00

Signed-off-by: Piotr Sikora