| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| |
|
|
|
|
|
|
| |
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>
|
| |
|
|
| |
No functional changes.
|
| |
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
If fastcgi end request record was split between several network packets,
with fastcgi_keep_conn it was possible that connection was saved in incorrect
state (e.g. with padding bytes not yet read).
|
| |
|
|
|
|
| |
Checks for f->padding before state transitions make code hard to follow,
remove them and make sure we always do another loop iteration after
f->state is set to ngx_http_fastcgi_st_padding.
|
| |
|
|
|
|
|
|
|
|
| |
With fastcgi_keep_conn it was possible that connection was closed after
FCGI_STDERR record with zero padding and without any further data read yet.
This happended as f->state was set to ngx_http_fastcgi_st_padding and then
"break" happened, resulting in p->length being set to f->padding, i.e. 0
(which in turn resulted in connection close).
Fix is to make sure we continue the loop after f->state is set.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Found by Coverity.
|
| |
|
|
|
|
|
|
| |
Padding was incorrectly ignored on end request, empty stdout and stderr
fastcgi records. This resulted in protocol desynchronization if fastcgi
application used these records with padding for some reason.
Reported by Ilia Vinokurov.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
By default follow the old behaviour, i.e. FASTCGI_KEEP_CONN flag isn't set
in request and application is responsible for closing connection once request
is done. To keep connections alive fastcgi_keep_conn must be activated.
|
| |
|
|
| |
The bug had appeared in r3561 (fastcgi), r3638 (scgi), r3567 (uwsgi).
|
| | |
|
| |
|
|
| |
is given by expression and refers to a defined upstream
|
| |
|
|
|
| |
patch by Maxim Dounin
the bug has been introduced in r3461
|
| | |
|
| |
|
|
| |
a limit_except block if no handler was defined for the block
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
delete ngx_http_cache(), ngx_http_no_cache_set_slot()
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
because it is anyway very seldom case
|
| | |
|
| |
|
|
|
|
| |
fastcgi_upstream_max_fails, fastcgi_upstream_fail_timeout,
memcached_upstream_max_fails, and memcached_upstream_fail_timeout
directives obsolete since 0.5.0 version
|
| | |
|
| | |
|
| |
|
|
| |
the bug had been introduced in r3461
|
