| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
| |
The proxy_store, fastcgi_store, scgi_store and uwsgi_store were inherited
incorrectly if a directive with variables was defined, and then redefined
to the "on" value, i.e. in configurations like:
proxy_store /data/www$upstream_http_x_store;
location / {
proxy_store on;
}
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The proxy_pass directive and other handlers are not expected to be inherited
into nested locations, but there is a special code to inherit upstream
handlers into limit_except blocks, as well as a configuration into if{}
blocks. This caused incorrect behaviour in configurations with nested
locations and limit_except blocks, like this:
location / {
proxy_pass http://u;
location /inner/ {
# no proxy_pass here
limit_except GET {
# nothing
}
}
}
In such a configuration the limit_except block inside "location /inner/"
unexpectedly used proxy_pass defined in "location /", while it shouldn't.
Fix is to avoid inheritance of conf->upstream.upstream (and
conf->proxy_lengths) into locations which don't have noname flag.
|
| |
|
|
|
|
|
|
|
| |
Instead of independant inheritance of conf->upstream.upstream (proxy_pass
without variables) and conf->proxy_lengths (proxy_pass with variables)
we now test them both and inherit only if neither is set. Additionally,
SSL context is also inherited only in this case now.
Based on the patch by Alexey Radkov.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The upstream modules remove and alter a number of client headers
before sending the request to upstream. This set of headers is
smaller or even empty when cache is disabled.
It's still possible that a request in a cache-enabled location is
uncached, for example, if cache entry counter is below min_uses.
In this case it's better to alter a smaller set of headers and
pass more client headers to backend unchanged. One of the benefits
is enabling server-side byte ranges in such requests.
|
| |
|
|
| |
No functional changes.
|
| |
|
|
| |
No functional changes.
|
| |
|
|
|
|
| |
Once this age is reached, the cache lock is discarded and another
request can acquire the lock. Requests which failed to acquire
the lock are not allowed to cache the response.
|
| |
|
|
| |
Signed-off-by: Piotr Sikora <piotr@cloudflare.com>
|
| |
|
|
|
|
| |
The directives limit the upstream read rate. For example,
"proxy_limit_rate 42" limits proxy upstream read rate to
42 bytes per second.
|
| |
|
|
|
| |
The directives enable byte ranges for both cached and uncached
responses regardless of backend headers.
|
| |
|
|
|
|
|
| |
The new directives {proxy,fastcgi,scgi,uwsgi,memcached}_next_upstream_tries
and {proxy,fastcgi,scgi,uwsgi,memcached}_next_upstream_timeout limit
the number of upstreams tried and the maximum time spent for these tries
when searching for a valid upstream.
|
| |
|
|
|
| |
In fastcgi, scgi and uwsgi modules there are no default cache keys, and
using a cache without a cache key set is likely meaningless.
|
| | |
|
| |
|
|
| |
Signed-off-by: Piotr Sikora <piotr@cloudflare.com>
|
| | |
|
| |
|
|
|
| |
Just a merge of proxy_ssl_name, proxy_ssl_verify commits into uwsgi module,
code is identical.
|
| |
|
|
|
|
|
|
|
|
| |
The SSL_CTX_set_cipher_list() may fail if there are no valid ciphers
specified in proxy_ssl_ciphers / uwsgi_ssl_ciphers, resulting in
SSL context leak.
In theory, ngx_pool_cleanup_add() may fail too, but this case is
intentionally left out for now as it's almost impossible and proper fix
will require changes to http ssl and mail ssl code as well.
|
| |
|
|
|
|
|
|
| |
Previously, upstream's status code was overwritten with
cached response's status code when STALE or REVALIDATED
response was sent to the client.
Signed-off-by: Piotr Sikora <piotr@cloudflare.com>
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Found by Coverity Scan CID 1135525.
Signed-off-by: Piotr Sikora <piotr@cloudflare.com>
|
| | |
|
| |
|
|
| |
Based on patch by Roberto De Ioris.
|
| |
|
|
|
| |
Notably this fixes HTTP_IF_MODIFIED_SINCE which was always sent with
cache enabled in fastcgi/scgi/uwsgi after 43ccaf8e8728.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The following new directives are introduced: proxy_cache_revalidate,
fastcgi_cache_revalidate, scgi_cache_revalidate, uwsgi_cache_revalidate.
Default is off. When set to on, they enable cache revalidation using
conditional requests with If-Modified-Since for expired cache items.
As of now, no attempts are made to merge headers given in a 304 response
during cache revalidation with headers previously stored in a cache item.
Headers in a 304 response are only used to calculate new validity time
of a cache item.
|
| |
|
|
|
| |
This was missed in 9d59a8eda373 when non-buffered support was added to SCGI
and uwsgi.
|
| |
|
|
|
|
|
|
|
| |
The parameter is mostly identical to http_404, and is expected to
be used in similar situations. The 403 code might be returned by
a backend instead of 404 on initial sync of new directories with rsync.
See here for feature request and additional details:
http://mailman.nginx.org/pipermail/nginx-ru/2013-April/050920.html
|
| | |
|
| |
|
|
| |
Prodded by Roberto De Ioris.
|
| |
|
|
|
|
|
| |
The "proxy_bind", "fastcgi_bind", "uwsgi_bind", "scgi_bind" and
"memcached_bind" directives are now inherited; inherited value
can be reset by the "off" parameter. Duplicate directives are
now detected. Parameter value can now contain variables.
|
| |
|
|
|
| |
This makes conversion from strings to complex values possible
without the loss of functionality.
|
| |
|
|
|
|
|
|
|
| |
Failing to do so results in problems if 400 or 414 requests are
redirected to fastcgi/scgi/uwsgi upstream, as well as after invalid
headers got from upstream. This was already fixed for proxy in r3478,
but fastcgi (the only affected protocol at that time) was missed.
Reported by Matthieu Tourne.
|
| | |
|
| |
|
|
|
|
|
|
| |
This resulted in a disclosure of previously freed memory if upstream
server returned specially crafted response, potentially exposing
sensitive information.
Reported by Matthew Daley.
|
| |
|
|
|
| |
Fixed incorrect use of r->http_version (r4372). Removed duplicate function
declaration (r4373). Removed error if there is no Status header (r4374).
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The following problems were fixed:
1. Directive fastcgi_cache affected headers sent to backends in unrelated
servers / locations (see ticket #45).
2. If-Unmodified-Since, If-Match and If-Range headers were sent to backends
if fastcgi_cache was used.
3. Cache-related headers were sent to backends if there were no fastcgi_param
directives and fastcgi_cache was used at server level.
|
| |
|
|
| |
No functional changes.
|
| |
|
|
| |
Patch by Peter Smit.
|
| |
|
|
| |
The bug had appeared in r3561 (fastcgi), r3638 (scgi), r3567 (uwsgi).
|
| | |
|
| |
|
|
| |
is given by expression and refers to a defined upstream
|
| |
|
|
| |
a limit_except block if no handler was defined for the block
|
| | |
|
| | |
|
| | |
|
