| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
Now it includes not only the received body size,
but the size of headers block as well.
|
|
|
|
|
|
Setting rb->bufs to NULL is surplus after ngx_http_write_request_body()
has returned NGX_OK.
|
|
Previously, only r->method was changed, resulting in handling of a request
as GET within nginx itself, but not in requests to proxied servers.
See http://mailman.nginx.org/pipermail/nginx/2015-December/049518.html.
|
|
|
|
|
|
This was broken in a93345ee8f52 (1.9.8).
|
|
This flag makes sub filter flush buffered data and optimizes allocation in copy
filter.
|
|
With main request buffered, it's possible, that a slice subrequest will send
output before it. For example, while main request is waiting for aio read to
complete, a slice subrequest can start an aio operation as well. The order
in which aio callbacks are called is undetermined.
|
|
Skip SSL_CTX_set_tlsext_servername_callback in case of renegotiation.
Do nothing in SNI callback as in this case it will be supplied with
request in c->data which isn't expected and doesn't work this way.
This was broken by b40af2fd1c16 (1.9.6) with OpenSSL master branch and LibreSSL.
|
|
Splits a request into subrequests, each providing a specific range of response.
The variable "$slice_range" must be used to set subrequest range and proper
cache key. The directive "slice" sets slice size.
The following example splits requests into 1-megabyte cacheable subrequests.
server {
listen 8000;
location / {
slice 1m;
proxy_cache cache;
proxy_cache_key $uri$is_args$args$slice_range;
proxy_set_header Range $slice_range;
proxy_cache_valid 200 206 1h;
proxy_pass http://127.0.0.1:9000;
}
}
|
|
|
|
The NGX_PTR_SIZE macro is only needed in preprocessor directives where
it's not possible to use sizeof().
|
|
|
|
This is an API change.
The proxy module was modified to not depend on this in 44122bddd9a1.
No known third-party modules seem to depend on this.
|
|
Do not assume that space character follows the method name, just pass it
explicitly.
The fuss around it has already proved to be unsafe, see bbdb172f0927 and
http://mailman.nginx.org/pipermail/nginx-ru/2013-January/049692.html for
details.
|
|
|
|
The previous default of 256 bytes isn't enough and results in two
allocations on each accepted connection, which is suboptimal.
|
|
|
|
If an upstream with variables evaluated to address without a port,
then instead of a "no port in upstream" error an attempt was made
to connect() which failed with EADDRNOTAVAIL.
|
|
|
|
|
|
The HEADERS frame is always represented by more than one buffer since
b930e598a199, but the handling code hasn't been adjusted.
Only the first buffer of HEADERS frame was checked and if it had been
sent while others had not, the rest of the frame was dropped, resulting
in broken connection.
Before b930e598a199, the problem could only be seen in case of HEADERS
frame with CONTINUATION.
|
|
The r->invalid_header flag wasn't reset once an invalid header appeared in a
request, resulting in all subsequent headers in the request were also marked
as invalid.
|
|
The directive toggles conversion of HEAD to GET for cacheable proxy requests.
When disabled, $request_method must be added to cache key for consistency.
By default, HEAD is converted to GET as before.
|
|
OpenSSL doesn't check if the negotiated protocol has been announced.
As a result, the client might force using HTTP/2 even if it wasn't
enabled in configuration.
|
|
It caused inconsistency between setting "in_closed" flag and the moment when
the last DATA frame was actually read. As a result, the body buffer might not
be initialized properly in ngx_http_v2_init_request_body(), which led to a
segmentation fault in ngx_http_v2_state_read_data(). Also it might cause
start processing of incomplete body.
This issue could be triggered when the processing of a request was delayed,
e.g. in the limit_req or auth_request modules.
|
|
Now it limits only the maximum length of literal string (either raw or
compressed) in HPACK request header fields. It's easier to understand
and to describe in the documentation.
|
|
|
|
No functional changes.
|
|
Previously, it didn't work well for 0, 127, and 128, returning less than needed.
|
|
|
|
Previous code has been based on assumption that the header block can only be
splitted at the borders of individual headers. That wasn't the case and might
result in emitting frames bigger than the frame size limit.
The current approach is to split header blocks by the frame size limit.
|
|
No functional changes.
|
|
|
|
|
|
Previously, nginx worker would crash because of a double free
if client disconnected or timed out before sending all headers.
Found with afl-fuzz.
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
|
|
Previously, streams that were indirectly reprioritized (either because of
a new exclusive dependency on their parent or because of removal of their
parent from the dependency tree), didn't have their pointer to the parent
node updated.
This broke detection of circular dependencies and, as a result, nginx
worker would crash due to stack overflow whenever such dependency was
introduced.
Found with afl-fuzz.
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
|
|
Per RFC7540, a stream cannot depend on itself.
Previously, this requirement was enforced on PRIORITY frames, but not on
HEADERS frames and due to the implementation details nginx worker would
crash (stack overflow) while opening self-dependent stream.
Found with afl-fuzz.
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
|
|
The case when an integer is out of frame bounds should be checked first
as a more accurate error.
|
|
No functional changes.
|
|
Variable names are not null-terminated, so using ngx_strncmp() without
extra length checks is wrong.
Reported by Markus Linnala,
http://mailman.nginx.org/pipermail/nginx-devel/2015-August/007211.html.
|
|
Previously, a configuration with "root" set to an empty string tried test
a character at clcf->root.data[-1]. Additional test added to make sure
this won't happen.
Reported by Markus Linnala, see
http://mailman.nginx.org/pipermail/nginx-devel/2015-August/007210.html.
|
|
|
|
|
|
|
|
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.
|
