nginx.git/src/http, branch release-1.13.10

gRPC: fixed missing state save in frame header parsing.

2018-03-20T12:58:11+00:00

Previously, frame state wasn't saved if HEADERS frame payload
that begins with header fragment was not received at once.

HTTP/2: improved frame info debugging.

2018-03-19T18:32:15+00:00

gRPC: fixed parsing response headers split on CONTINUATION frames.

2018-03-19T13:42:56+00:00

Fixed checking ngx_tcp_push() and ngx_tcp_nopush() return values.

2018-03-19T13:28:23+00:00

No functional changes.

Upstream: fixed comments after 13f8dec720b5.

2018-03-19T13:22:09+00:00

The fields "uri", "location", and "url" from ngx_http_upstream_conf_t
moved to ngx_http_proxy_loc_conf_t and ngx_http_proxy_vars_t, reflect
this change in create_loc_conf comments.

gRPC: special handling of "trailer only" responses.

2018-03-17T20:04:26+00:00

The gRPC protocol makes a distinction between HEADERS frame with
the END_STREAM flag set, and a HEADERS frame followed by an empty
DATA frame with the END_STREAM flag.  The latter is not permitted,
and results in errors not being propagated through nginx.  Instead,
gRPC clients complain that "server closed the stream without sending
trailers" (seen in grpc-go) or "13: Received RST_STREAM with error
code 2" (seen in grpc-c).

To fix this, nginx now returns HEADERS with the END_STREAM flag if
the response length is known to be 0, and we are not expecting
any trailer headers to be added.  And the response length is
explicitly set to 0 in the gRPC proxy if we see initial HEADERS frame
with the END_STREAM flag set.

gRPC: special handling of the TE request header.

2018-03-17T20:04:25+00:00

According to the gRPC protocol specification, the "TE" header is used
to detect incompatible proxies, and at least grpc-c server rejects
requests without "TE: trailers".

To preserve the logic, we have to pass "TE: trailers" to the backend if
and only if the original request contains "trailers" in the "TE" header.
Note that no other TE values are allowed in HTTP/2, so we have to remove
anything else.

The gRPC proxy module.

2018-03-17T20:04:24+00:00

The module allows passing requests to upstream gRPC servers.
The module is built by default as long as HTTP/2 support is compiled in.
Example configuration:

    grpc_pass 127.0.0.1:9000;

Alternatively, the "grpc://" scheme can be used:

    grpc_pass grpc://127.0.0.1:9000;

Keepalive support is available via the upstream keepalive module.  Note
that keepalive connections won't currently work with grpc-go as it fails
to handle SETTINGS_HEADER_TABLE_SIZE.

To use with SSL:

    grpc_pass grpcs://127.0.0.1:9000;

SSL connections use ALPN "h2" when available.  At least grpc-go works fine
without ALPN, so if ALPN is not available we just establish a connection
without it.

Tested with grpc-c++ and grpc-go.

Upstream: u->conf->preserve_output flag.

2018-03-17T20:04:23+00:00

The flag can be used to continue sending request body even after we've
got a response from the backend.  In particular, this is needed for gRPC
proxying of bidirectional streaming RPCs, and also to send control frames
in other forms of RPCs.

Upstream: u->request_body_blocked flag.

2018-03-17T20:04:22+00:00

The flag indicates whether last ngx_output_chain() returned NGX_AGAIN
or not.  If the flag is set, we arm the u->conf->send_timeout timer.
The flag complements c->write->ready test, and allows to stop sending
the request body in an output filter due to protocol-specific flow
control.