Sandbox Directives

This directive defines the maximum time to wait for existing requests to complete before exiting or restarting Appweb.

This directive defines the maximum size of the Appweb data cache. This cache store is used for caching responses and for the session state date for ESP applications. If the maximum size is exceeded, Appweb will prune the oldest data in the cache to make room for newer items.

This directive defines the maximum size of a single item in the Appweb data cache. This cache store is used for caching responses and for the session state date for ESP applications. If the maximum size is exceeded, Appweb will not store the item in the cache. The request will continue, but not be served from the cache.

This directive defines the maximum chunk size when using Transfer Chunk Encoding.

The LimitClients directive defines the maximum number of simultaneous client systems that can connect to the server. Connections in excess of this count will be rejected. Set to "unlimited" for no limit.

This directive counts the number of unique client systems. A system with many users all using the same IP address will be counted as one client.

The LimitConnections directive defines the maximum number of simultaneous client connections to the server. Connections in excess of this count will be rejected. Set to "unlimited" for no limit.

This directive counts the number of client socket connections. A single browser may open many separate connections (typically up to 6).

The LimitConnectionsPerClient directive defines the maximum number of simultaneous client connections to the server from a single IP address. Connections in excess of this count will be rejected. Set to "unlimited" for no limit.

This directive counts the number of client socket connections from a single IP address. A single browser may open many separate connections (typically up to 6).

The LimitFiles directive defines the maximum number of files/sockets that Appweb can open on a Unix system. The files limit must be set sufficiently high to support the peak load anticipated for Appweb. Each request will always consume one file descriptor for the network socket. CGI requests will consume an additional three file descriptors to communicate with the CGI process.

The default limit for Appweb is defined by the system ulimit. A limit of '0' means set the limit to the maximum permitted by the operating system.

This directive defines the maximum number of requests that may be serviced using a single TCP/IP connection.

Limiting the number to a reasonable maximum can help reduce the impact of some denial of service attacks.

The LimitMemory directive defines the maximum amount of memory that Appweb can use. On Linux and MacOSX, where a fast memory size API exists, this is the amount of memory currently used by the application. On other platforms, it is the amount of Appweb heap memory and does not include thread stack, code allocations, or memory allocated by means other than the MPR memory allocation primitives. If the memory limit is exceeded, Appweb will invoke the policy specified by the MemoryPolicy directive.

This directive defines the maximum packet size in bytes for each stage in the request pipeline. This directive places a limit on the amount of memory consumed by pipeline stages.

NOTE: this does not imply a maximum response size (See LimitResponseBody for that functionality). It merely limits the memory consumed when trying to process the response data. Appweb handlers will flush the packets and use HTTP/1.1 chunked output if the amount of response data exceeds the output packet size.

If using HTTP/2, the packet size will never be less than 16K which is the minimum frame size supported by HTTP/2.

This directive was called "LimitBuffer" in earlier versions.

The LimitProcesses directive defines the maximum number of processes that Appweb will spawn to serve CGI processes. If this maximum is exceeded, Appweb will deny the request.

The LimitRequestsPerClient directive defines the maximum number of simultaneous client HTTP requests that are permitted per single client IP address. Requests in excess of this count will be rejected. Set to "unlimited" for no limit.

NOTE: that many browsers can and will initiate multiple requests when requesting a page. Some browsers will initiate up to six requests at a time for a single tab.

To mitigate denial of service attacks, this limit should be set as low as possible.

The LimitRequestBody directive defines a maximum size for the request body. For embedded applications, it is useful to limit the request body to the expected maximum. This ensures that rogue or malicious requests will not cause the server to allocate unwanted memory to servicing the request.

The limit is an integer between zero and 2147483647 (2GB). Set to "unlimited" for no limit. If a request is received that is larger than the limit, it will be rejected and the client will receive an error. The default limit is 64 MB.

This directive can be quite useful in certain denial-of-service attacks where the attacker sends large documents of a certain type.

The LimitRequestForm directive defines a maximum size for the request form data. Form data is encoded with a Content-Type of "application/x-www-form-urlencoded". Form data is fully buffered before doing Route matching and constructing the pipeline. Whereas, non-form data is streamed to the handler and not buffered.

For embedded applications, it is useful to limit the request body to the expected maximum. This ensures that rogue or malicious requests will not cause the server to allocate unwanted memory to servicing the request.

The limit is an integer between zero and 2147483647 (2GB). Set to "unlimited" for no limit. If a request is received that is larger than the limit, it will be rejected and the client will receive an error. The default limit is 64 MB.

This directive can be quite useful in certain denial-of-service attacks where the attacker sends large documents of a certain type.

The LimitRequestHeader directive defines the maximum size of the request header from the client. For embedded applications, it is useful to limit the size of the header to the expected maximum. This ensures that rogue or malicious requests will not cause the server to allocate unwanted memory to servicing the request. Typically, HTTP requests will not have more than 4K of header data.

The limit is an integer between zero and 1 MB. Set to "unlimited" for no limit. If a request is received that has a header larger than the limit, it will be rejected and the client will receive an error. The default limit is 8 K.

This directive can be quite useful in certain denial-of-service attacks where the attacker sends requests with large bogus headers.

The LimitRequestHeaderLines directive defines a maximum number of header lines that may be in a request from a client. For embedded applications, it is useful to limit the number of header lines to the expected maximum. This ensures that rogue or malicious requests will not cause the server to allocate unwanted memory to servicing the request. Typically, HTTP requests will not have more than 15-20 header lines.

The limit is an integer between zero and 4096. Set to "unlimited" for no limit. If a request is received that has more header lines than the limit, it will be rejected and the client will receive an error. The default limit is 40.

This directive can be quite useful in certain denial-of-service attacks where the attacker sends requests with many spurious header lines.

The LimitResponseBody directive defines the maximum size for response body data. Set to "unlimited" for no limit

The LimitSessions directive defines the maximum number of simultaneous client sessions that utilize server-side session state storage. Requests in excess of this count will be rejected. Set to "unlimited" for no limit.

This directive limits the number of session states, whereas the LimitClients directive limits the number of connected client systems.

NOTE: that many browsers can and will initiate multiple requests when requesting a page. These will share the same session state storage. Some browsers will initiate up to six requests at a time for a single tab.

The LimitStreams directive defines the maximum number of simultaneous HTTP/2 streams per client connection for HTTP/2. The default limit is 20.

The LimitUri directive defines the maximum size of a URL in Appweb. In embedded applications, it is useful to limit the number of header lines to the expected maximum. This ensures that rogue or malicious requests will not cause the server to allocate unwanted memory to servicing the request.

The limit is an integer between zero and 256 K. Set to "unlimited" for no limit. If a request is received that has a URL larger than the limit, it will be rejected and the client will receive an error. The default limit is 4 K.

This directive can be quite useful in certain denial-of-service attacks where the attacker sends requests with bogus URLs.

The LimitUpload directive defines the maximum size of an uploaded file. In embedded applications, it is useful to limit the maximum file upload size to ensure that rogue or malicious requests will not cause the server to allocate unwanted space for uploads.

Set to "unlimited" for no limit. If a file larger than the limit is uploaded, Appweb will reject the request and the client will receive an error. The default value is unlimited.

This directive can be quite useful in certain denial-of-service attacks where the attacker sends requests with bogus URLs.

Appweb manages memory proactively and ensures reliable operation by preventing memory allocation errors before they occur. It does this by defining a memory limit and applying a memory policy for how to react when memory is depleted.

The MemoryPolicy directive defines how Appweb will respond to low memory conditions. While the LimitMemory directive defines a maximum amount of memory that Appweb is permitted to use, the MemoryPolicy directive defines how Appweb will respond when the limit is approached and exceeded.

If memory utilization exceeds the maximum memory limit, Appweb will invoke the memory depletion policy defined by this directive. Appweb also institutes a memory redline that is 85% of the memory limit. When memory utilization exceeds the redline value, Appweb will issue a warning to the error log and attempt to free non-essential memory such as old session data and request caching.

If the memory policy is set to continue, Appweb will prune all non-essential memory, but will continue to run. i.e. the limit becomes a soft limit and can be exceeded. If the policy is set to restart, then Appweb will do a graceful restart if the maximum is exceeded. A graceful restart will allow existing requests to complete up to the timeout specified by the ExitTimeout directive. Appweb relies on the appman manager application to restart appweb in this case.

If the memory policy is set to abort, Appweb will abort and dump core. Ensure you set the system ulimit core value correctly so that core dumps are generated by the system.

The MinWorkers directive will pre-allocate the specified number of worker threads on startup and then ensure that the worker pool always has at least this minimum number of workers.

Appweb will automatically adjust the number of workers between the minimum specified by this directive and the maximum specified by the WorkerLimit directive or via the Appweb command line. Every ten minutes, Appweb will prune workers that have been idle for five minutes to reduce resource consumption.

Appweb has two non-worker threads: one for the master event loop and one for the garbage collector. So the total number of Appweb threads will be two plus the number of active workers.

The ThreadStack directive defines the size of the thread stack to allocate for each thread. The limit is an integer between zero and an operating system defined maximum  where zero means use the system default. The default limit is zero which implies the system default.

The LimitWebSocketsMessage directive defines the maximum size of a Web Sockets message.

This defines the maximum packet size for a portion of a Web Sockets message.

This specifies the maximum frame size used for Web Sockets messages when sent over the wire.

The LimitWorkers directive defines a maximum number of threads for the Appweb thread pool. When running in multithreaded mode, Appweb will use a pool thread to service each request and then will return the thread to the pool. This results in a highly responsive and scalable architecture with excellent throughput characteristics. Each thread requires a thread stack and thus consumes memory. By limiting the number of threads, memory can be conserved.

If the maximum number of threads is also specified via the Appweb command line, the command line value will take precedence.

Appweb will automatically adjust the number of pool threads between the minimum specified by the MinWorkers directive and the maximum specified by this directive. Appweb will prune idle threads to reduce resource consumption as required.