| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| | |
|
| |
|
|
| |
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.
|
| |
|
|
|
| |
This allows to handle requests with chunked body by scgi module, and
also simplifies handling of various request body modifications.
|
| |
|
|
|
|
|
|
|
| |
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 SCGI specification doesn't specify format of the response, and assuming
CGI specs should be used there is no reason to complain. RFC 3875
explicitly states that "A Status header field is optional, and status
200 'OK' is assumed if it is omitted".
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
The r->http_version is a version of client's request, and modules must
not set it unless they are really willing to downgrade protocol version
used for a response (i.e. to HTTP/0.9 if no response headers are available).
In neither case r->http_version may be upgraded.
The former code downgraded response from HTTP/1.1 to HTTP/1.0 for no reason,
causing various problems (see ticket #66). It was also possible that
HTTP/0.9 requests were upgraded to HTTP/1.0.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
delete ngx_http_cache(), ngx_http_no_cache_set_slot()
|
| | |
|
| | |
|
| | |
|
| |
|
