The HTTP server section in Nginx

The HTTP server section, or the HTTP configuration context, is available unless you have built NGINX without the HTTP module (--without-http). This section controls all aspects of working with the HTTP module and will probably be the one that you will use the most.

The configuration directives found in this section deals with handling the HTTP connections. As such, there are quite a number of directives defined by this module. We will divide these directives up by type, to be able to talk about them more easily.

Client directives

This set of directives deals with the aspects of the client connection itself, as well as with different types of client.

The HTTP client directives

Explanation

chunked_transfer_encoding

This directive allows disabling the standard HTTP/1.1 chunked transfer encoding in responses to clients.

client_body_buffer_size

This directive is used to set a buffer size for the client request body that is larger than the default two memory pages, in order to prevent temporary files from being written to disk.

client_body_in_file_only

This directive is used for debugging or further processing of the client request body. This directive can be set to on to force save the client request body to a file.

client_body_in_single_buffer

This directive forces NGINX to save the entire client request body in a single buffer to reduce the copy operations.

client_body_temp_path

This directive defines a directory path for saving the client request body.

client_body_timeout

This directive specifies the length of time between the successive read operations of the client body.

client_header_buffer_size

This directive is used for specifying a buffer size for the client request header, when this needs to be larger than the default size of 1 KB.

client_header_timeout

This timeout is the length of time for reading the entire client header.

client_max_body_size

This directive defines the largest allowable client request body, before a 413 (Request Entity Too Large) error is returned to the browser.

keepalive_disable

This directive disables keepalive request for certain browser types.

keepalive_requests

This directive defines how many requests may be made over one keepalive connection before it is closed.

keepalive_timeout

This directive specifies how long a keepalive connection will stay open. A second parameter may be given to set a keepalive header in the response.

large_client_header_buffers

This directive defines the maximum number and size of a large client request header.

msie_padding

This directive enables the disabling of adding comments to responses with a status greater than 400 for MSIE clients, in order to pad the response size to 512 bytes.

msie_refresh

This directive enables the sending of a refresh instead of a redirect for the MSIE clients.

File I/O directives

File I/O directives control how NGINX delivers static files and/or how it manages file descriptors.

HTTP file I/O directives

Explanation

aio

This directive enables the use of asynchronous file I/O. It is available on all modern versions of FreeBSD and distributions of Linux. On FreeBSD, aio may be used to preload data for sendfile. Under Linux, directio is required, which automatically disables sendfile.

directio

This directive enables the operating system specific flag or function for serving files larger than the given parameter. It’s required when using aio on Linux.

directio_alignment

This directive sets the alignment for directio. The default value of 512 is usually enough, although it’s recommended to increase this to 4 K when using XFS on Linux.

open_file_cache

This directive configures a cache that can store open file descriptors, directory lookups, and file lookup errors.

open_file_cache_errors

This directive enables the caching of file lookup errors by open_file_cache.

open_file_cache_min_uses

This directive configures the minimum number of uses for a file within the inactive parameter to open_file_cache for the file descriptor to remain open in the cache.

open_file_cache_valid

This directive specifies the time interval between validity checks for items in open_file_cache.

postpone_output

This directive specifies the minimum size of data for NGINX to send to the client. If possible, no data will be sent until this value is reached.

read_ahead

If possible, the kernel will pre-read files up to the size parameter. It’s supported on current FreeBSD and Linux (the size parameter is ignored on Linux).

sendfile

This directive enables using sendfile(2) to directly copy the data from one file descriptor to another.

sendfile_max_chunk

This directive sets the maximum size of data to copy in one sendfile(2) call, to prevent a worker from seizing.

Hash directives

The set of hash directives controls how large a range of static memory NGINX allocates to certain variables. NGINX will calculate the minimum size needed on startup and reconfiguration. You will, most likely, only need to adjust one of the *_hash_max_size parameters by setting the appropriate directive when NGINX emits a warning to that effect. The *_hash_bucket_size variables are set by default to a multiple of the processor’s cache line size to minimize the lookups needed to retrieve the entry and therefore should not normally be changed. Refer to http://nginx.org/en/docs/hash.html for additional details.

HTTP hash directives

Explanation

server_names_hash_bucket_size

This directive specifies the bucket size used to hold the server_name hash tables.

server_names_hash_max_size

This directive specifies the maximum size of the server_name hash tables.

types_hash_bucket_size

This directive specifies the bucket size used to hold the types hash tables.

types_hash_max_size

This directive specifies the maximum size of the types hash tables.

variables_hash_bucket_size

This directive specifies the bucket size used to hold the remaining variables.

variables_hash_max_size

This directive specifies the maximum size of the hash that holds the remaining variables.

Socket directives

Socket directives describe how NGINX can set various options on the TCP sockets it creates.

HTTP socket directives

Explanation

lingering_close

This directive specifies how a client connection will be kept open for more data.

lingering_time

In connection with the lingering_close directive, this directive will specify how long a client connection will be kept open for processing more data.

lingering_timeout

Also in conjunction with lingering_close, this directive indicates how long NGINX will wait for additional data before closing the client connection.

reset_timedout_connection

With this directive enabled, connections that have been timed out will immediately be reset, freeing all associated memory. The default is to leave the socket in the FIN_WAIT1 state, which will always be the case for keepalive connections.

send_lowat

If nonzero, NGINX will try to minimize the number of send operations on client sockets. It is ignored on Linux, Solaris, and Windows.

send_timeout

This directive sets a timeout between two successive write operations for a client receiving a response.

tcp_nodelay

This directive enables or disables the TCP_NODELAY option for keepalive connections.

tcp_nopush

This directive is relevant only when sendfile is used. It enables NGINX to attempt to send response headers in one packet, as well as sending a file in full packets.

Sample configuration

The following code is an example of an HTTP configuration section:

http {

    include       /opt/local/etc/nginx/mime.types;

    default_type  application/octet-stream;

    sendfile on;

    tcp_nopush on;

    tcp_nodelay on;

    keepalive_timeout  65;

    server_names_hash_max_size 1024;

}

This context block would go after any global configuration directives in the nginx.conf file.

Related Articles

How to add swap space on Ubuntu 21.04 Operating System

How to add swap space on Ubuntu 21.04 Operating System

The swap space is a unique space on the disk that is used by the system when Physical RAM is full. When a Linux machine runout the RAM it use swap space to move inactive pages from RAM. Swap space can be created into Linux system in two ways, one we can create a...

read more

Lorem ipsum dolor sit amet consectetur

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

13 − 7 =