uWSGI#

Allows passing requests to a uWSGI server.

When building from the source code, the module is built by default; it can be disabled with the build option --without-http_uwsgi_module.

In packages and images from our repositories, the module is included in the build.

Related guides

Console Light Web Panel: cache zones fill the Caches tab.

Configuration Example#

location / {
    include    uwsgi_params;
    uwsgi_pass localhost:9000;
}

Directives#

uwsgi_bind#

Syntax	`uwsgi_bind` address [`transparent`] \| `off`;
Default	—
Context	http, server, location

Makes outgoing connections to a uwsgi server originate from the specified local IP address with an optional port. Parameter value can contain variables. The special value off cancels the effect of the uwsgi_bind directive inherited from the previous configuration level, which allows the system to auto-assign the local IP address and port.

By default, this value is evaluated once when the request is initialized, before a uwsgi server is selected. In Angie PRO, evaluation happens after each uwsgi server selection (including retries), so the bind address can depend on the selected server; for example, via the $upstream_current_addr variable. If the evaluated value is empty, no binding is made.

The transparent parameter allows outgoing connections to a uwsgi server originate from a non-local IP address, for example, from a real IP address of a client:

uwsgi_bind $remote_addr transparent;

In order for this parameter to work, it is usually necessary to run Angie worker processes with the superuser privileges. On Linux it is not required as if the transparent parameter is specified, worker processes inherit the CAP_NET_RAW capability from the master process.

Note

It is necessary to configure kernel routing table to intercept network traffic from the uwsgi server.

uwsgi_buffer_size#

Syntax	`uwsgi_buffer_size` size;
Default	`uwsgi_buffer_size 4k\|8k;`
Context	http, server, location

Sets the size of the buffer used for reading the first part of the response received from the uwsgi server. This part usually contains a small response header. By default, the buffer size is equal to one memory page. This is either 4K or 8K, depending on a platform. It can be made smaller, however.

uwsgi_buffering#

Syntax	`uwsgi_buffering` `on` \| `off`;
Default	`uwsgi_buffering on;`
Context	http, server, location

Enables or disables buffering of responses from the uwsgi server.

on

Angie sends the response to the client in parallel with reading it from the uwsgi server; the client does not wait for the whole response. The response is read into the buffers set by the uwsgi_buffer_size and uwsgi_buffers directives. A buffer is passed for sending once it is completely filled, and the total size of the buffers busy sending is limited by uwsgi_busy_buffers_size. A partially filled buffer waits until it fills up or the response ends, so data normally reaches the client in whole buffers. Responses that must reach the client as they are produced therefore need off. Part of the response is written to a temporary file on disk when all buffers are full and the client reads slower than the uwsgi server sends. Responses that are cached or stored on disk always pass through a temporary file. Writing to temporary files is controlled by the uwsgi_max_temp_file_size and uwsgi_temp_file_write_size directives. Buffering frees the uwsgi server as soon as that server has sent its whole response, instead of holding the connection to it for as long as a slow client takes to read.

off

Every portion of data read from the uwsgi server is passed to the client immediately, with no minimum size: 10 bytes read from a 4K buffer are sent right away. Angie uses a single buffer, set by the uwsgi_buffer_size directive, so it reads no more than that size at a time. No temporary file is used, so responses are neither cached nor stored on disk, and neither uwsgi_limit_rate nor limit_rate has any effect. off suits responses that must reach the client as they are produced: Server-Sent Events, long polling, and streaming.

Buffering can also be enabled or disabled by passing "yes" or "no" in the X-Accel-Buffering response header field. This capability can be disabled using the uwsgi_ignore_headers directive.

uwsgi_buffers#

Syntax	`uwsgi_buffers` number size;
Default	`uwsgi_buffers 8 4k \| 8k;`
Context	http, server, location

Sets the number and size of the buffers used for reading a response from the uwsgi server, for a single connection.

By default, the buffer size is equal to one memory page. This is either 4K or 8K, depending on a platform.

uwsgi_busy_buffers_size#

Syntax	`uwsgi_busy_buffers_size` size;
Default	`uwsgi_busy_buffers_size 8k \| 16k;`
Context	http, server, location

When buffering of responses from the uwsgi server is enabled, limits the total size of buffers that can be busy sending a response to the client while the response is not yet fully read. In the meantime, the rest of the buffers can be used for reading the response and, if needed, buffering part of the response to a temporary file.

By default, size is limited by the size of two buffers set by the uwsgi_buffer_size and uwsgi_buffers directives.

uwsgi_cache#

Syntax	`uwsgi_cache` zone \| `off`;
Default	`uwsgi_cache off;`
Context	http, server, location

Defines a shared memory zone used for caching. The same zone can be used in several places. Parameter value can contain variables.

off

disables caching inherited from the previous configuration level.

Note

When using uwsgi_cache, you typically need to also set the uwsgi_cache_valid directive to explicitly specify the caching time for responses. If it's not set, Angie doesn't use default values but determines the response caching time based on HTTP response headers from the server in the following priority order:

The X-Accel-Expires header (highest priority).
The Cache-Control header with max-age or s-maxage parameters.
The Expires header.

If none of these headers contain valid values or are not present at all, the response will not be cached because its expiration time cannot be determined.

uwsgi_cache_background_update#

Syntax	`uwsgi_cache_background_update` `on` \| `off`;
Default	`uwsgi_cache_background_update off;`
Context	http, server, location

Allows starting a background subrequest to update an expired cache item, while a stale cached response is returned to the client.

Warning

Note that it is necessary to allow the usage of a stale cached response when it is being updated.

uwsgi_cache_bypass#

Syntax	`uwsgi_cache_bypass` string ...;
Default	—
Context	http, server, location

Defines conditions under which the response will not be taken from a cache. If at least one value of the string parameters is not empty and is not equal to "0" then the response will not be taken from the cache:

uwsgi_cache_bypass $cookie_nocache $arg_nocache$arg_comment;
uwsgi_cache_bypass $http_pragma    $http_authorization;

Parameter values can contain variables.

Can be used along with the uwsgi_no_cache directive.

uwsgi_cache_key#

Syntax	`uwsgi_cache_key` string;
Default	—
Context	http, server, location

Defines a key for caching. The key can contain variables. For example

uwsgi_cache_key localhost:9000$request_uri;

uwsgi_cache_lock#

Syntax	`uwsgi_cache_lock` `on` \| `off`;
Default	`uwsgi_cache_lock off;`
Context	http, server, location

When enabled, only one request at a time will be allowed to populate a new cache element identified according to the uwsgi_cache_key directive by passing a request to a uwsgi server. Other requests of the same cache element will either wait for a response to appear in the cache or the cache lock for this element to be released, up to the time set by the uwsgi_cache_lock_timeout directive.

uwsgi_cache_lock_age#

Syntax	`uwsgi_cache_lock_age` time;
Default	`uwsgi_cache_lock_age 5s;`
Context	http, server, location

If the last request passed to the uwsgi server for populating a new cache element has not completed for the specified time, one more request may be passed to the uwsgi server.

uwsgi_cache_lock_timeout#

Syntax	`uwsgi_cache_lock_timeout` time;
Default	`uwsgi_cache_lock_timeout 5s;`
Context	http, server, location

Sets a timeout for uwsgi_cache_lock. When the time expires, the request will be passed to the uwsgi server, however, the response will not be cached.

uwsgi_cache_max_range_offset#

Syntax	`uwsgi_cache_max_range_offset` number;
Default	—
Context	http, server, location

Sets an offset in bytes for byte-range requests. If the range is beyond the offset, the range request will be passed to the uwsgi server and the response will not be cached.

uwsgi_cache_methods#

Syntax	`uwsgi_cache_methods` `GET` \| `HEAD` \| `POST` ...;
Default	`uwsgi_cache_methods GET HEAD;`
Context	http, server, location

If the client request method is listed in this directive then the response will be cached. "GET" and "HEAD" methods are always added to the list, though it is recommended to specify them explicitly. See also the uwsgi_no_cache directive.

uwsgi_cache_min_uses#

Syntax	`uwsgi_cache_min_uses` number;
Default	`uwsgi_cache_min_uses 1;`
Context	http, server, location

Sets the number of requests after which the response will be cached.

Warning

Cache metadata is stored in shared memory. Manually deleting cache files does not reset the counters and may lead to unpredictable behavior. To completely reset the cache, stop the server, delete the cache directory, and start again.

Note

Third-party cache purge modules (e.g., Cache Purge) only delete files but do not reset the uwsgi_cache_min_uses counter. The directive is intended to protect the cache from pollution by infrequent requests, and resetting the counter on purge could negatively impact performance.

uwsgi_cache_path#

Syntax	`uwsgi_cache_path` path [`levels=`levels] [`use_temp_path=on` \| `off`] `keys_zone=`name:size[:`file=`file] [`inactive=`time] [`max_size=`size] [`min_free=`size] [`manager_files=`number] [`manager_sleep=`time] [`manager_threshold=`time] [`loader_files=`number] [`loader_sleep=`time] [`loader_threshold=`time];
Default	—
Context	http

Sets the path and other parameters of a cache. Cache data are stored in files. The file name in a cache is a result of applying the MD5 function to the cache key.

levels

defines hierarchy levels of a cache: from 1 to 3, each level accepts values 1 or 2.

For example, in the following configuration:

uwsgi_cache_path /data/angie/cache levels=1:2 keys_zone=one:10m;

file names in a cache will look like this:

/data/angie/cache/c/29/b7f54b2df7773722d382f4809d65029c

A cached response is first written to a temporary file, and then the file is renamed. Temporary files and the cache can be put on different file systems. However, be aware that in this case a file is copied across two file systems instead of the cheap renaming operation. It is thus recommended that for any given location both cache and a directory holding temporary files are put on the same file system.

`use_temp_path=on` \| `off`	determines the directory to be used for temporary files
`on`	If the parameter is not specified or set to `on`, the directory specified by the uwsgi_temp_path directive for the given location will be used
`off`	temporary files will be placed directly in the cache directory
`keys_zone`	Sets the name and size of the shared memory zone for storing all active keys and information about data. Cache metadata is stored in shared memory. The zone size is specified in bytes and must be at least two system memory pages. The `k` and `m` suffixes are also accepted; unlike `max_size`, this parameter does not accept `g`. A zone of 1 megabyte is sufficient to store about 8000 keys. When an optional file is specified with `keys_zone`, Angie dumps the contents of this zone to disk when the main process terminates and attempts to restore it at the same memory address on the next startup or after binary upgrade, to ensure more reliable data persistence and reduce cache loading time. If the file has incompatible content, for example because an incompatible build wrote it, Angie renames it with the `.old` suffix, logs `discarded due to incompatible content`, and creates the zone anew. The cache loader then fills the zone from the cache directory, as on a start without the file, so cached responses are not lost. You can either delete the renamed file, or restore its name and revert Angie to the configuration and version in which this file was originally created. If the zone size in the configuration no longer matches the size saved in the file, the configuration fails to load until the file is removed or the original size is restored. The configuration also fails to load if the zone cannot be mapped at the memory address saved in the file: Angie logs `mmap(MAP_ANON\|MAP_SHARED, ...) failed` if that address is already in use, or `failed to restore zone at address` if the operating system maps the zone at a different address. Warning Make sure the path to the file is specified correctly and has the necessary access permissions for Angie to use, and is protected from unauthorized access; relative paths are based on the prefix.
`inactive`	If cached data is not accessed within the time set by this parameter, it is removed, regardless of its freshness; each access resets this timer. This differs from the size-based eviction performed by the cache manager described below: inactivity-based removal applies even when the cache is below `max_size`, and it ignores the validity periods configured with uwsgi_cache_valid. By default, `inactive` is 10 minutes.

A special cache manager process monitors the maximum cache size and the minimum amount of free space on the file system with cache, and when the size is exceeded or there is not enough free space, it removes the least recently used data. The data is removed in iterations.

`max_size`	maximum threshold value for cache size The value is specified in bytes; the `k`, `m`, and `g` suffixes are also accepted. By default, the cache size is not limited.
`min_free`	minimum threshold value for free space on the file system with cache The value is specified in the same units as `max_size`. The default value `0` disables free space monitoring. On platforms that do not support querying file system statistics, the parameter is ignored, and Angie logs the warning `min_free is not supported on this platform, ignored`.
`manager_files`	maximum number of cache items deleted in one iteration Default: `100`
`manager_threshold`	limits the time of one iteration Default: `200` milliseconds
`manager_sleep`	time for which a pause is maintained between iterations Default: `50` milliseconds

One minute after Angie starts, a special cache loader process is activated, which loads information about previously cached data stored on the filesystem into the cache zone. Loading also occurs in iterations.

loader_files

maximum number of cache items to load in one iteration

Default: 100

loader_threshold

limits the time of one iteration

Default: 200 milliseconds

loader_sleep

time for which a pause is maintained between iterations

Default: 50 milliseconds

uwsgi_cache_revalidate#

Syntax	`uwsgi_cache_revalidate` `on` \| `off`;
Default	`uwsgi_cache_revalidate off;`
Context	http, server, location

Enables revalidation of expired cache items using conditional requests with the If-Modified-Since and If-None-Match header fields.

uwsgi_cache_use_stale#

Syntax	`uwsgi_cache_use_stale` `error` \| `timeout` \| `invalid_header` \| `updating` \| `http_500` \| `http_503` \| `http_403` \| `http_404` \| `http_429` \| `non_idempotent` \| `off` ...;
Default	`uwsgi_cache_use_stale off;`
Context	http, server, location

Determines in which cases a stale cached response can be used. The directive's parameters match the parameters of the uwsgi_next_upstream directive.

`error`	Permits using a stale cached response if a uwsgi server to process a request cannot be selected.
`updating`	Additional parameter, permits using a stale cached response if it is currently being updated. This allows minimizing the number of accesses to uwsgi servers when updating cached data.
`non_idempotent`	Permits using a stale cached response if a request with a non-idempotent method has already been sent to a uwsgi server and communication with that server then fails for any reason; of the non-idempotent methods only `POST` can be cached, and uwsgi_cache_methods must enable it.

Using a stale cached response can also be enabled directly in the response header for a specified number of seconds after the response became stale:

The stale-while-revalidate extension of the Cache-Control header field permits using a stale cached response if it is currently being updated.
The stale-if-error extension of the Cache-Control header field permits using a stale cached response in case of an error.

Note

This method has lower priority than setting directive parameters.

To minimize the number of requests to uwsgi servers when populating a new cache element, the uwsgi_cache_lock directive can be used.

uwsgi_cache_valid#

Syntax	`uwsgi_cache_valid` [code ... \| `any`] time;
Default	—
Context	http, server, location

Sets caching time for different response codes. For example, the following directives

uwsgi_cache_valid 200 302 10m;
uwsgi_cache_valid 404      1m;

set 10 minutes of caching for responses with codes 200 and 302 and 1 minute for responses with code 404.

If only caching time is specified,

uwsgi_cache_valid 5m;

then only 200, 301, and 302 responses are cached.

In addition, it can be specified to cache any responses using the any parameter:

uwsgi_cache_valid 200 302 10m;
uwsgi_cache_valid 301      1h;
uwsgi_cache_valid any      1m;

Note

Caching parameters can also be set directly in the response header. This method has higher priority than setting caching time using the directive.

The X-Accel-Expires header field sets caching time of a response in seconds. The value 0 disables caching for a response. If the value starts with the @ prefix, it sets an absolute time in seconds since Epoch, up to which the response may be cached.
If the header does not include the X-Accel-Expires field, caching parameters are determined by the Expires or Cache-Control header fields.
A response with the Set-Cookie header field will not be cached.
A response with the Vary header field with the special value "*" will not be cached. A response with the Vary header field with another value will be cached taking into account the corresponding request header fields.

Processing of one or more of these header fields can be disabled using the uwsgi_ignore_headers directive.

uwsgi_connect_timeout#

Syntax	`uwsgi_connect_timeout` time;
Default	`uwsgi_connect_timeout 60s;`
Context	http, server, location

Defines a timeout for establishing a connection with a uwsgi server. It should be noted that this timeout cannot usually exceed 75 seconds.

uwsgi_connection_drop#

Syntax	`uwsgi_connection_drop` time \| `on` \| `off`;
Default	`uwsgi_connection_drop off;`
Context	http, server, location

Enables termination of all active connections to the proxied server after it has been removed from the group or marked as permanently unavailable by a reresolve process or the API command DELETE. Idle connections in the cache are not affected.

A connection is terminated when the next read or write event is processed for either the client or the proxied server.

Setting time enables a connection termination timeout; with on set, connections are dropped immediately.

uwsgi_force_ranges#

Syntax	`uwsgi_force_ranges` `on` \| `off`;
Default	`uwsgi_force_ranges off;`
Context	http, server, location

Enables byte-range support for both cached and uncached responses from a uwsgi server regardless of the presence of the Accept-Ranges field in these responses.

uwsgi_hide_header#

Syntax	`uwsgi_hide_header` field;
Default	—
Context	http, server, location

By default, Angie does not pass the header fields Date, Server, X-Pad, and X-Accel-... from the response of a uwsgi server to a client. The uwsgi_hide_header directive sets additional fields that will not be passed. If, conversely, the passing of fields needs to be permitted, the uwsgi_pass_header directive can be used.

uwsgi_ignore_client_abort#

Syntax	`uwsgi_ignore_client_abort` `on` \| `off`;
Default	`uwsgi_ignore_client_abort off;`
Context	http, server, location

Determines whether the connection with a uwsgi server should be closed when a client closes the connection without waiting for a response.

uwsgi_ignore_headers#

Syntax	`uwsgi_ignore_headers` field ...;
Default	—
Context	http, server, location

Disables processing of certain response header fields from the uwsgi server. The following fields can be ignored: X-Accel-Redirect, X-Accel-Expires, X-Accel-Limit-Rate, X-Accel-Buffering, X-Accel-Charset, Expires, Cache-Control, Set-Cookie, and Vary.

If not disabled, processing of these header fields has the following effect:

X-Accel-Expires, Expires, Cache-Control, Set-Cookie, and Vary set the parameters of response caching;
X-Accel-Redirect performs an internal redirect to the specified URI or named location;
X-Accel-Limit-Rate sets the rate limit for transmission of a response to a client;
X-Accel-Buffering enables or disables buffering of a response;
X-Accel-Charset sets the desired charset of a response.

uwsgi_intercept_errors#

Syntax	`uwsgi_intercept_errors` `on` \| `off`;
Default	`uwsgi_intercept_errors off;`
Context	http, server, location

Determines whether uwsgi server responses with codes greater than or equal to 300 should be passed to a client or be intercepted and redirected to Angie for processing with the error_page directive.

uwsgi_limit_rate#

Syntax	`uwsgi_limit_rate` rate;
Default	`uwsgi_limit_rate 0;`
Context	http, server, location

Limits the speed of reading the response from the uwsgi server. The rate is specified in bytes per second and can contain variables.

`0`	disables rate limiting

Note

The limit is set per a request, and so if Angie simultaneously opens two connections to the uwsgi server, the overall rate will be twice as much as the specified limit. The limitation works only if buffering of responses from the uwsgi server is enabled.

uwsgi_max_temp_file_size#

Syntax	`uwsgi_max_temp_file_size` size;
Default	`uwsgi_max_temp_file_size 1024m;`
Context	http, server, location

When buffering of responses from the uwsgi server is enabled, and the whole response does not fit into the buffers set by the uwsgi_buffer_size and uwsgi_buffers directives, a part of the response can be saved to a temporary file. This directive sets the maximum size of the temporary file. The size of data written to the temporary file at a time is set by the uwsgi_temp_file_write_size directive.

`0`	disables buffering of responses to temporary files

Note

This restriction does not apply to responses that will be cached or stored on disk.

uwsgi_modifier1#

Syntax	`uwsgi_modifier1` number;
Default	`uwsgi_modifier1 0;`
Context	http, server, location

Sets the value of the modifier1 field in the uwsgi packet header.

uwsgi_modifier2#

Syntax	`uwsgi_modifier2` number;
Default	`uwsgi_modifier2 0;`
Context	http, server, location

Sets the value of the modifier2 field in the uwsgi packet header.

uwsgi_next_upstream#

Syntax	`uwsgi_next_upstream` `error` \| `timeout` \| `invalid_header` \| `http_500` \| `http_503` \| `http_403` \| `http_404` \| `http_429` \| `non_idempotent` \| `off` ...;
Default	`uwsgi_next_upstream error timeout;`
Context	http, server, location

Specifies in which cases a request should be passed to the next server in the upstream group:

`error`	a connection error, request transmission error, or response header reading error occurred;
`timeout`	a timeout occurred during connection establishment, request transmission, or response header reading;
`invalid_header`	the server returned an empty or invalid response;
`http_500`	the server returned a response with code 500;
`http_503`	the server returned a response with code 503;
`http_403`	the server returned a response with code 403;
`http_404`	the server returned a response with code 404;
`http_429`	the server returned a response with code 429;
`non_idempotent`	normally, requests with non-idempotent methods (`POST`, `LOCK`, `PATCH`) are not passed to another server if a request to an upstream server has already been sent; enabling this parameter explicitly allows retrying such requests;
`off`	disables passing a request to the next server.

Note

It should be understood that passing a request to the next server is only possible if nothing has been sent to the client yet. That is, if an error or timeout occurs in the middle of the transmission of a response, fixing this is impossible.

The directive also defines what is considered an unsuccessful attempt of communication with a server.

error

timeout

invalid_header

are always considered unsuccessful attempts, even if they are not specified in the directive

http_500

http_503

http_429

are considered unsuccessful attempts only if they are specified in the directive

http_403

http_404

are never considered unsuccessful attempts

Passing a request to the next server can be limited by the number of tries and by time.

uwsgi_next_upstream_timeout#

Syntax	`uwsgi_next_upstream_timeout` time;
Default	`uwsgi_next_upstream_timeout 0;`
Context	http, server, location

Limits the time during which a request can be passed to the next server.

`0`	turns off this limitation

uwsgi_next_upstream_tries#

Syntax	`uwsgi_next_upstream_tries` number;
Default	`uwsgi_next_upstream_tries 0;`
Context	http, server, location

Limits the number of possible tries for passing a request to the next server.

`0`	turns off this limitation

uwsgi_no_cache#

Syntax	`uwsgi_no_cache` string ...;
Default	—
Context	http, server, location

Defines conditions under which the response will not be saved to a cache. If at least one value of the string parameters is not empty and is not equal to "0" then the response will not be saved:

uwsgi_no_cache $cookie_nocache $arg_nocache$arg_comment;
uwsgi_no_cache $http_pragma    $http_authorization;

Parameter values can contain variables.

Can be used along with the uwsgi_cache_bypass directive.

uwsgi_param#

Syntax	`uwsgi_param` parameter value [`if_not_empty`];
Default	—
Context	http, server, location

Sets a parameter that should be passed to the uwsgi server. The value can contain variables. These directives are inherited from the previous configuration level if and only if there are no uwsgi_param directives defined on the current level.

Standard CGI environment variables should be provided as uwsgi headers, see the uwsgi_params file provided in the distribution:

location / {
    include uwsgi_params;
#    ...
}

In the standard uwsgi_params file, REQUEST_METHOD is set to $upstream_request_method.

If the directive is specified with if_not_empty then such a parameter will be passed to the server only if its value is not empty:

uwsgi_param HTTPS $https if_not_empty;

uwsgi_pass#

Syntax	`uwsgi_pass` [protocol://]address;
Default	—
Context	location, if in location

Sets the protocol and address of a uwsgi server. As a protocol, uwsgi or suwsgi (secured uwsgi, uwsgi over SSL) can be specified. The address can be specified as a domain name or IP address, and a port:

uwsgi_pass localhost:9000;
uwsgi_pass uwsgi://localhost:9000;
uwsgi_pass suwsgi://[2001:db8::1]:9090;

or as a UNIX domain socket path specified after the word unix and enclosed in colons:

uwsgi_pass unix:/tmp/uwsgi.socket;

If a domain name resolves to several addresses, all of them will be used in a round-robin fashion. In addition, an address can be specified as a server group.

Parameter value can contain variables. In this case, if an address is specified as a domain name, the name is searched among the described server groups, and, if not found, is determined using a resolver.

Note

If uwsgi_pass is specified in a location with a trailing slash in the prefix (for example, location /name/), and the auto_redirect directive is set to default, requests without a trailing slash will be redirected (/name -> /name/).

uwsgi_pass_header#

Syntax	`uwsgi_pass_header` field;
Default	—
Context	http, server, location

Permits passing otherwise disabled header fields from a uwsgi server to a client.

uwsgi_pass_request_body#

Syntax	`uwsgi_pass_request_body` `on` \| `off`;
Default	`uwsgi_pass_request_body on;`
Context	http, server, location

Indicates whether the original request body is passed to the uwsgi server. See also the uwsgi_pass_request_headers directive.

uwsgi_pass_request_headers#

Syntax	`uwsgi_pass_request_headers` `on` \| `off`;
Default	`uwsgi_pass_request_headers on;`
Context	http, server, location

Enables or disables passing of header fields from the original request to the uwsgi server. See also the uwsgi_pass_request_body directive.

uwsgi_read_timeout#

Syntax	`uwsgi_read_timeout` time;
Default	`uwsgi_read_timeout 60s;`
Context	http, server, location

Defines a timeout for reading a response from the uwsgi server. The timeout is set only between two successive read operations, not for the transmission of the whole response. If the uwsgi server does not transmit anything within this time, the connection is closed.

uwsgi_request_buffering#

Syntax	`uwsgi_request_buffering` `on` \| `off`;
Default	`uwsgi_request_buffering on;`
Context	http, server, location

Enables or disables buffering of a client request body.

`on`	The request body is fully read from the client before sending the request to the uwsgi server.
`off`	The request body is sent to the uwsgi server immediately as it is received. In this case, the request cannot be passed to the next server if Angie has already started sending the request body.

When HTTP/1.1 chunked transfer encoding is used to send the original request body, then the request body will be buffered regardless of the directive value.

uwsgi_send_timeout#

Syntax	`uwsgi_send_timeout` time;
Default	`uwsgi_send_timeout 60s;`
Context	http, server, location

Sets a timeout for transmitting a request to the uwsgi server. The timeout is set only between two successive write operations, not for the transmission of the whole request. If the uwsgi server does not receive anything within this time, the connection is closed.

uwsgi_socket_keepalive#

Syntax	`uwsgi_socket_keepalive` `on` \| `off`;
Default	`uwsgi_socket_keepalive off;`
Context	http, server, location

Configures the "TCP keepalive" behavior for outgoing connections to a uwsgi server.

`off`	By default, the operating system's settings are in effect for the socket.
`on`	The SO_KEEPALIVE socket option is turned on for the socket.

uwsgi_ssl_certificate#

Syntax	`uwsgi_ssl_certificate` file \| `data:`certificate;
Default	—
Context	http, server, location

Specifies the certificate in the PEM format used for authentication to a secured uwsgi server.

The value is interpreted as in ssl_certificate: a file path, or the PEM text of the certificate after the data: prefix. The value can contain variables; they are evaluated each time Angie establishes a connection to the secured uwsgi server, so all variables of the request are available, including those assigned by set. If the evaluated certificate value is empty, no client certificate is sent. To avoid loading certificates for every connection, enable uwsgi_ssl_certificate_cache.

uwsgi_ssl_certificate_cache#

Syntax

uwsgi_ssl_certificate_cache off;

uwsgi_ssl_certificate_cache max=N [inactive=time] [valid=time];

Default

uwsgi_ssl_certificate_cache off;

Context

http, server, location

Defines a cache that stores SSL certificates and secret keys specified using variables.

The directive supports the following parameters:

max — sets the maximum number of elements in the cache. When the cache overflows, the least recently used (LRU) elements are removed.
inactive — defines the time after which an element is removed if it has not been accessed during this time, even if still within its valid period; each access resets this timer. The default is 10 seconds.
valid — defines the time during which a cached element is reused without checks. The default is 60 seconds. After this period, an element loaded from a file is reloaded only if the file has changed, and a key loaded with the engine: or store: prefix is loaded again; an element specified with the data: prefix stays valid.
off — disables the cache.

Keys protected by a passphrase (see uwsgi_ssl_password_file) are not cached.

Example:

uwsgi_ssl_certificate       /etc/angie/ssl/$host.crt;
uwsgi_ssl_certificate_key   /etc/angie/ssl/$host.key;
uwsgi_ssl_certificate_cache max=1000 inactive=20s valid=1m;

uwsgi_ssl_certificate_key#

Syntax	`uwsgi_ssl_certificate_key` file \| `data:`key \| `engine:`name`:`id \| `store:`uri;
Default	—
Context	http, server, location

Specifies the secret key in the PEM format used for authentication to a secured uwsgi server.

The value, including the engine: and store: prefixes, is interpreted as in ssl_certificate_key, and variables in it work as described in uwsgi_ssl_certificate. A key protected by a passphrase is decrypted with the passphrases from uwsgi_ssl_password_file.

uwsgi_ssl_ciphers#

Syntax	`uwsgi_ssl_ciphers` ciphers;
Default	`uwsgi_ssl_ciphers DEFAULT;`
Context	http, server, location

Specifies the enabled ciphers for requests to a secured uwsgi server. The ciphers are specified in the format understood by the OpenSSL library.

The list of ciphers depends on the version of OpenSSL installed. The full list can be viewed using the openssl ciphers command.

Warning

With OpenSSL, the uwsgi_ssl_ciphers directive does not configure TLS 1.3 ciphers; set them with the Ciphersuites command of the uwsgi_ssl_conf_command directive instead. The uwsgi_ssl_ciphers directive ignores TLS 1.3 cipher names in its value, so such names do not restrict TLS 1.3 connections. If the value consists only of such names, for example TLS_AES_128_GCM_SHA256, the configuration fails to load with the no cipher match error.

With LibreSSL, TLS 1.3 ciphers can be configured using uwsgi_ssl_ciphers.
With BoringSSL, TLS 1.3 ciphers cannot be configured at all.

uwsgi_ssl_conf_command#

Syntax	`uwsgi_ssl_conf_command` name value;
Default	—
Context	http, server, location

Sets arbitrary OpenSSL configuration commands when establishing a connection with a secured uwsgi server.

Note

The directive is supported when using OpenSSL 1.0.2 or higher. The Ciphersuites command, which sets TLS 1.3 ciphers, requires OpenSSL 1.1.1 or higher.

Multiple uwsgi_ssl_conf_command directives can be specified on the same level. These directives are inherited from the previous configuration level if and only if there are no uwsgi_ssl_conf_command directives defined on the current level.

Warning

Note that reconfiguring OpenSSL directly might result in unexpected behavior.

uwsgi_ssl_crl#

Syntax	`uwsgi_ssl_crl` file;
Default	—
Context	http, server, location

Specifies a file with revoked certificates (CRL) in the PEM format used to verify the certificate of the secured uwsgi server.

uwsgi_ssl_name#

Syntax	`uwsgi_ssl_name` name;
Default	uwsgi_ssl_name `host name from uwsgi_pass;`
Context	http, server, location

Allows overriding the server name used to verify the certificate of the secured uwsgi server and to be passed through SNI when establishing a connection with the secured uwsgi server.

The server name can also be specified with variables.

By default, the host name from the uwsgi_pass directive is used.

uwsgi_ssl_password_file#

Syntax	`uwsgi_ssl_password_file` file;
Default	—
Context	http, server, location

Specifies a file with passphrases for secret keys where each passphrase is specified on a separate line. Passphrases are tried in turn when loading the key.

uwsgi_ssl_protocols#

Syntax	`uwsgi_ssl_protocols` `SSLv2` \| `SSLv3` \| `TLSv1` \| `TLSv1.1` \| `TLSv1.2` \| `TLSv1.3` ...;
Default	`uwsgi_ssl_protocols TLSv1.2 TLSv1.3;`
Context	http, server, location

Enables the specified protocols for requests to a secured uwsgi server.

uwsgi_ssl_server_name#

Syntax	`uwsgi_ssl_server_name` `on` \| `off`;
Default	`uwsgi_ssl_server_name off;`
Context	http, server, location

Enables or disables passing the server name set by the uwsgi_ssl_name directive via the Server Name Indication TLS extension (SNI, RFC 6066) while establishing a connection with the secured uwsgi server.

uwsgi_ssl_session_reuse#

Syntax	`uwsgi_ssl_session_reuse` `on` \| `off`;
Default	`uwsgi_ssl_session_reuse on;`
Context	http, server, location

Determines whether SSL sessions can be reused when working with the secured uwsgi server. If the SSL3_GET_FINISHED:digest check failed error appears in the logs, try disabling session reuse.

uwsgi_ssl_trusted_certificate#

Syntax	`uwsgi_ssl_trusted_certificate` file;
Default	—
Context	http, server, location

Specifies a file with trusted CA certificates in the PEM format used to verify the certificate of the uwsgi HTTPS server.

uwsgi_ssl_verify#

Syntax	`uwsgi_ssl_verify` `on` \| `off`;
Default	`uwsgi_ssl_verify off;`
Context	http, server, location

Enables or disables verification of the uwsgi server certificate.

uwsgi_ssl_verify_depth#

Syntax	`uwsgi_ssl_verify_depth` number;
Default	`uwsgi_ssl_verify_depth 1;`
Context	http, server, location

Sets the verification depth in the uwsgi server certificates chain.

uwsgi_store#

Syntax	`uwsgi_store` `on` \| `off` \| string;
Default	`uwsgi_store off;`
Context	http, server, location

Enables saving of files to a disk.

`on`	saves files with paths corresponding to the directives alias or root
`off`	disables saving of files

The file name can be set explicitly using the string with variables:

uwsgi_store /data/www$original_uri;

The modification time of files is set according to the received Last-Modified response header field. The response is first written to a temporary file, and then the file is renamed. Temporary files and the persistent store can be put on different file systems. However, be aware that in this case a file is copied across two file systems instead of the cheap renaming operation. It is thus recommended that for any given location both saved files and a directory holding temporary files, set by the uwsgi_temp_path directive, are put on the same file system.

This directive can be used to create local copies of static unchangeable files, e.g.:

location /images/ {
    root               /data/www;
    error_page         404 = /fetch$uri;
}

location /fetch/ {
    internal;

    uwsgi_pass         backend:9000;
    ...

    uwsgi_store        on;
    uwsgi_store_access user:rw group:rw all:r;
    uwsgi_temp_path    /data/temp;

    alias              /data/www/;
}

uwsgi_store_access#

Syntax	`uwsgi_store_access` users:permissions [users:permissions] [users:permissions];
Default	`uwsgi_store_access user:rw;`
Context	http, server, location

Sets access permissions for newly created files and directories, e.g.:

uwsgi_store_access user:rw group:rw all:r;

If any group or all access permissions are specified then user permissions may be omitted:

uwsgi_store_access group:rw all:r;

uwsgi_temp_file_write_size#

Syntax	`uwsgi_temp_file_write_size` size;
Default	`uwsgi_temp_file_write_size 8k\|16k;`
Context	http, server, location

Limits the size of data written to a temporary file at a time, when buffering of responses from the uwsgi server to temporary files is enabled. By default, size is limited by two buffers set by the uwsgi_buffer_size and uwsgi_buffers directives. The maximum size of a temporary file is set by the uwsgi_max_temp_file_size directive.

uwsgi_temp_path#

Syntax	`uwsgi_temp_path` path [level1 [level2 [level3]]];
Default	`uwsgi_temp_path uwsgi_temp;` (the path depends on the build parameter `--http-uwsgi-temp-path`)
Context	http, server, location

Defines a directory for storing temporary files with data received from uwsgi servers. Up to three-level subdirectory hierarchy can be used underneath the specified directory. For example, in the following configuration

uwsgi_temp_path /spool/angie/uwsgi_temp 1 2;

a temporary file might look like this:

/spool/angie/uwsgi_temp/7/45/00000123457

See also the use_temp_path parameter of the uwsgi_cache_path directive.