FAQ

Page Discussion Edit History

NginxHttpCoreModule

Contents

Edit section: Synopsis Synopsis

Controls core features of Nginx's HTTP processing.

Edit section: Directives Directives

Edit section: alias alias

syntax: alias file-path|directory-path;

default: no

context: location

This directive assigns a path to be used for the indicated location. Note that it may look similar to the root directive, but the document root doesn't change, just the file system path used for the request.

For example: 

location  /i/ {
  alias  /spool/w3/images/;
}

The request "/i/top.gif" will return the file "/spool/w3/images/top.gif".

Alias can also be used in a regex specified location.

For example: 

location ~ ^/download/(.*)$ {
  alias /home/website/files/$1;
}

The request "/download/book.pdf" will return the file "/home/website/files/book.pdf"

It is possible to use variables in the replacement path.

Edit section: client_body_in_file_only client_body_in_file_only

syntax: client_body_in_file_only on|off

default: off

context: http, server, location

The directive forces nginx to always store a client request body into a temporary disk file even if the body is actually of 0 size.

Please note that the file will not be removed at request completion if the directive is enabled.

This directive can be used for debugging and for the $r->request_body_file method in the Embedded Perl module.

Edit section: client_body_in_single_buffer client_body_in_single_buffer

syntax: client_body_in_single_buffer

default: off

context: http, server, location

The directive(0.7.58+) specifies whether to keep the whole body in a single client request buffer. The directive is recommended when using the variable $request_body to reduce the operations of copying.

Note that when the request body cannot be hold in a single buffer (see client_body_buffer_size), the body will still touch the disk.

Edit section: client_body_buffer_size client_body_buffer_size

syntax: client_body_buffer_size the_size

default: 8k/16k

context: http, server, location

The directive specifies the client request body buffer size.

If the request body is more than the buffer, then the entire request body or some part is written in a temporary file.

The default size is equal to two pages size, depending on platform it is either 8K or 16K.

Edit section: client_body_temp_path client_body_temp_path

syntax: client_body_temp_path dir-path [ level1 [ level2 [ level3 ]

default: client_body_temp

context: http, server, location

The directive assigns the directory for storing the temporary files in it with the body of the request.

In the dir-path a hierarchy of subdirectories up to three levels are possible.

For example 

client_body_temp_path  /spool/nginx/client_temp 1 2;

The directory structure will be like this: 

/spool/nginx/client_temp/7/45/00000123457

Edit section: client_body_timeout client_body_timeout

syntax: client_body_timeout time

default: 60

context: http, server, location

Directive sets the read timeout for the request body from client.

The timeout is set only if a body is not get in one readstep. If after this time the client send nothing, nginx returns error "Request time out" (408).

Edit section: client_header_buffer_size client_header_buffer_size

syntax: client_header_buffer_size size

default: 1k

context: http, server

Directive sets the headerbuffer size for the request header from client.

For the overwhelming majority of requests it is completely sufficient a buffer size of 1K.

However if a big cookie is in the request-header or the request has come from a wap-client the header can not be placed in 1K, therefore, the request-header or a line of request-header is not located completely in this buffer nginx allocate a bigger buffer, the size of the bigger buffer can be set with the instruction large_client_header_buffers.

Edit section: client_header_timeout client_header_timeout

syntax: client_header_timeout time

default: 60

context: http, server

Directive assigns timeout with reading of the title of the request of client.

The timeout is set only if a header is not get in one readstep. If after this time the client send nothing, nginx returns error "Request time out" (408).

Edit section: client_max_body_size client_max_body_size

syntax: client_max_body_size size

default: client_max_body_size 1m

context: http, server, location

Directive assigns the maximum accepted body size of client request, indicated by the line Content-Length in the header of request.

If size is greater the given one, then the client gets the error "Request Entity Too Large" (413).

It is necessary to keep in mind that the browsers do not know how to correctly show this error.

Edit section: default_type default_type

syntax: default_type MIME-type

default: default_type text/plain

context: http, server, location

Assigns the default MIME-type to be used for files where the standard MIME map doesn't specify anything.

See also types

Example: 

location = /proxy.pac {
  default_type application/x-ns-proxy-autoconfig;
}
location = /wpad.dat {
  rewrite . /proxy.pac;
  default_type application/x-ns-proxy-autoconfig;
}

Edit section: directio directio

syntax: directio [size|off]

default: directio off

context: http, server, location

The directive enables use of flags O_DIRECT (FreeBSD, Linux), F_NOCACHE (Mac OS X) or directio() function (Solaris) for reading files with size greater than specified. This directive disables use of sendfile for this request. This directive may be useful for big files: 

    directio  4m;

Edit section: error_page error_page

syntax: error_page code [ code... ] [ = | =answer-code ] uri | @named_location

default: no

context: http, server, location, if in location

The directive specifies the URI, which will be showed for the errors indicated.

Example: 

error_page   404          /404.html;
error_page   502 503 504  /50x.html;
error_page   403          http://example.com/forbidden.html;
error_page   404          = @fetch;

Furthermore, it is possible to change the code of answer to another, for example: 

error_page 404 =200 /.empty.gif;

If an erroneous answer is processed by the proxied or FastCGI server and this server can return the different answer codes, for example, 200, 302, 401 or 404, then it is possible to issue the code returned: 

error_page   404  =  /404.php;

If there is no need to change URI during redirection it is possible to redirect processing of error pages into a named location: 

location / (
    error_page 404 = @fallback;
)
 
location @fallback (
    proxy_pass http://backend;
)

Edit section: if_modified_since if_modified_since

syntax: if_modified_since [off|exact|before]

default: if_modified_since exact

context: http, server, location

The directive (0.7.24) defines how to compare time of file modification and time in request header "If-Modified-Since":

  • off — don't check "If-Modified-Since" request header (0.7.34);
  • exact — exact match;
  • before — file modification time should be less than time in "If-Modified-Since" request header.

Edit section: index index

syntax: index file [file...]

default: index index.html

context: http, server, location

Directive determines the file(s) which will be used as the index. It's possible to use variables in the name of file. The presence of the files is checked in the order of their enumeration. A file with an absolute path can be put at the end. Example using a variable: 

index  index.$geo.html  index.0.html  /index.html;

If you want to automatically generate an index from a directory listing, use autoindex on.


Edit section: internal internal

syntax: internal

default: no

context: location

internal indicates that the matching location can be used only for so called "internal" requests.

For external requests it will return the error "Not found" (404).

Internal requests are the following:

  • requests redirected by the instruction error_page
  • subrequests created by the command include virtual of the "ngx_http_ssi_module" module
  • requests changed by the instruction rewrite of the "ngx_http_rewrite_module" module

An example to prevent clients fetching error pages directly: 

error_page 404 /404.html;
location  /404.html {
  internal;
}

Edit section: keepalive_timeout keepalive_timeout

syntax: keepalive_timeout [ time ]

default: keepalive_timeout 75

context: http, server, location

The first parameter assigns the timeout for keep-alive connections with the client. The server will close connections after this time.

The optional second parameter assigns the time value in the header Keep-Alive: timeout=time of the response. This header can convince some browsers to close the connection, so that the server does not have to. Without this parameter, nginx does not send a Keep-Alive header (though this is not what makes a connection "keep-alive").

The parameters can differ from each other.

Notes on how browsers handle the Keep-Alive header:

  • MSIE and Opera ignore the "Keep-Alive: timeout=<N>" header.
  • MSIE keeps the connection alive for about 60-65 seconds, then sends a TCP RST.
  • Opera keeps the connection alive for a long time.
  • Mozilla keeps the connection alive for N plus about 1-10 seconds.
  • Konqueror keeps the connection alive for about N seconds.

Edit section: keepalive_requests keepalive_requests

syntax: keepalive_requests n

default: keepalive_requests 100

context: http, server, location

Number of requests which can be made over a keep-alive connection.

Edit section: large_client_header_buffers large_client_header_buffers

syntax: large_client_header_buffers number size

default: large_client_header_buffers 4 4k/8k

context: http, server

Directive assigns the maximum number and size of buffers for large headers to read from client request.

The request line can not be bigger than the size of one buffer, if the client send a bigger header nginx returns error "Request URI too large" (414).

The longest header line of request also must be not more than the size of one buffer, otherwise the client get the error "Bad request" (400).

Buffers are separated only as needed.

By default the size of one buffer is equal to the size of page, depending on platform this either 4K or 8K, if at the end of working request connection converts to state keep-alive, then these buffers are freed.

Edit section: limit_except limit_except

syntax: limit_except methods {...}

default: no

context: location

Directive limits HTTP-methods, accessible inside location.

For the limitation can be used the directives of modules ngx_http_access_module and ngx_http_auth_basic_module: 

limit_except  GET {
  allow  192.168.1.0/32;
  deny   all;
}

Edit section: limit_rate limit_rate

syntax: limit_rate speed

default: no

context: http, server, location, if in location

Directive assigns the speed of transmission of the answer to client. Speed is assigned in the bytes per second. Limitation works only for one connection, i.e., if client opens 2 connections, then total velocity will be 2 times higher then the limit set.

If it is necessary to limit speed for the part of the clients at the server level, based on some kind of condition - then this directive does not apply. Instead you should specify the limit by assigning the value to the $limit_rate variable, as shown below: 

server {
  if ($slow) {
    set $limit_rate  4k;
  }
}

You can also control the rate of individual responses returned by a proxy_pass response (NginxHttpProxyModule) by setting the X-Accel-Limit-Rate header (NginxXSendfile). This can be done without a X-Accel-Redirect header.

Edit section: limit_rate_after limit_rate_after

syntax: limit_rate_after time

default: limit_rate_after 1m

context: http, server, location, if in location

The directive limits speed only after the first part was sent. 

limit_rate_after 1m;
limit_rate 100k;

Edit section: listen listen

syntax: listen address:port [ default [ backlog=num | rcvbuf=size | sndbuf=size | accept_filter=filter | deferred | bind | ssl ] ]

default: listen 80

context: server

The listen directive specifies the address and port accepted by the enclosing server {...} block. It is possible to specify only an address, only a port, or a server name as the address. 

listen 127.0.0.1:8000;
listen 127.0.0.1;
listen 8000;
listen *:8000;
listen localhost:8000;

IPv6 address(0.7.36) are set in square brackets: 

listen [::]:8000; 
listen [fe80::1];

When Linux (in contrast to FreeBSD) binds IPv6 [::], it will also bind the corresponding IPv4 address. If other non IPv6 server definitions already used this, the bind will fail. By using explicit addresses instead of [::] this will not be a problem. It is also possible to specify that this listen directive is only to bind the IPv6 address with use of the "default ipv6only=on" option. Note that this only affect this listen directive, the same server {...} block may very well listen to IPv4 as well, specified by other listen directives. 

listen [2a02:750:5::123]:80;
listen [::]:80 default ipv6only=on;

If only address is given, the default port is 80.

If the directive has the default parameter, then the enclosing server {...} block will be the default server for the address:port pair. This is useful for name-based virtual hosting where you wish to specify the default server block for hostnames that do not match any server_name directives. If there are no directives with the default parameter, then the default server will be the first server block in which the address:port pair appears.

The listen directive accepts several parameters, specific to the system calls listen(2) and bind(2). These parameters must follow the default parameter.

backlog=num -- is assigned parameter backlog in call listen(2). By default backlog equals -1.

rcvbuf=size -- assigned to the parameter SO_RCVBUF for the listening socket.

sndbuf=size -- assigned to the parameter SO_SNDBUF for the listening socket.

accept_filter=filter -- is assigned name accept-filter.

. It works only to FreeBSD, it is possible to use two filters -- dataready and httpready. On the signal -HUP accept-filter it is possible to change only in the quite last versions FreeBSD: 6.0, 5.4-STABLE and 4.11-STABLE.

deferred -- indicates to use that postponed accept(2) on Linux with

. the aid of option TCP_DEFER_ACCEPT.

bind -- indicates that it is necessary to make bind(2) separately

. for this pair of address:port. The fact is that if are described several directives listen with the identical port, but by different addresses and one of the directives listen listens to on all addresses for this port (*:port), then nginx will make bind(2) only to *:port. It is necessary to consider that in this case for determining the address, on which the connections arrive, is done the system call getsockname(). But if are used parameters backlog, rcvbuf, sndbuf, accept_filter or deferred, then it is always done separately for this pair of address:port bind(2).

ssl -- parameter (0.7.14) not related to listen(2) and bind(2) syscalls

. but instead specifies that connections accepted on this port should work in SSL mode. This allows to specify compact configurations for servers working with both HTTP and HTTPS. For example: 

listen  80;
listen  443 default ssl;

Example of the use of the parameters: 

listen  127.0.0.1 default accept_filter=dataready backlog=1024;

Since version 0.8.21 nginx is able to listen on unix sockets: 

listen unix:/tmp/nginx1.sock;

Edit section: location location

syntax: location [=|~|~*|^~|@] /uri/ { ... }

default: no

context: server

This directive allows different configurations depending on the URI. It can be configured using both literal strings and regular expressions. To use regular expressions, you must use a prefix:

  1. "~" for case sensitive matching
  2. "~*" for case insensitive matching

To determine which location directive matches a particular query, the literal strings are checked first. Literal strings match the beginning portion of the query - the most specific match will be used. Afterwards, regular expressions are checked in the order defined in the configuration file. The first regular expression to match the query will stop the search. If no regular expression matches are found, the result from the literal string search is used.

For caseless operation systems, like Mac OS X and Cygwin, liternal string matching will be done in case insensitive way (0.7.7). However, comparision is limited to single-byte locale's only.

Regular expression may contain captures (0.7.40), which can be used in other directives.

It is possible to disable regular expression checks after liternal string matching by using "^~" prefix. If most specific match literal location have this prefix - regular expressions aren't checked.

By using "=" prefix on may define exact match between URI and location. On match search stops immediately as further search has no sense. E.g. if the request "/" occurs frequently, using "location = /" will speed up processing of this request a bit as search will stop after first comparison.

On exact match with literal location without "=" or "^~" prefixes search is also immediately terminated.

To summarize, the order in which directives are checked is as follows:

  1. Directives with the "=" prefix that match the query exactly. If found, searching stops.
  2. All remaining directives with conventional strings. If this match used the "^~" prefix, searching stops.
  3. Regular expressions, in the order they are defined in the configuration file.
  4. If #3 yielded a match, that result is used. Otherwise, the match from #2 is used.

It is important to know that nginx does the comparison against decoded URIs. For example, if you wish to match "/images/%20/test", then you must use "/images/ /test" to determine the location.

Example: 

location  = / {
  # matches the query / only.
  [ configuration A ] 
}
location  / {
  # matches any query, since all queries begin with /, but regular
  # expressions and any longer conventional blocks will be
  # matched first.
  [ configuration B ] 
}
location ^~ /images/ {
  # matches any query beginning with /images/ and halts searching,
  # so regular expressions will not be checked.
  [ configuration C ] 
}
location ~* \.(gif|jpg|jpeg)$ {
  # matches any request ending in gif, jpg, or jpeg. However, all
  # requests to the /images/ directory will be handled by
  # Configuration C.   
  [ configuration D ] 
}

Example requests:

  • / -> configuration A
  • /documents/document.html -> configuration B
  • /images/1.gif -> configuration C
  • /documents/1.jpg -> configuration D

Note that you could define these 4 configurations in any order and the results would remain the same. While nested locations are allowed by the configuration file parser, their use is discouraged and may produce unexpected results.

The prefix "@" specifies a named location. Such locations are not used during normal processing of requests, they are intended only to process internally redirected requests (see error_page, try_files).

Edit section: log_not_found log_not_found

syntax: log_not_found [on|off]

default: log_not_found on

context: http, server, location

The directive enables or disables messages in error_log about files not found on disk.

Edit section: log_subrequest log_subrequest

syntax: log_subrequest [on|off]

default: log_subrequest off

context: http, server, location

The directive enables or disables messages in access_log about sub-requests such as rewrite rules and/or SSI requests.

Edit section: msie_padding msie_padding

syntax: msie_padding [on|off]

default: msie_padding on

context: http, server, location

This directive enables or disables the the msie_padding feature for MSIE browsers, and Chrome (as of nginx 0.8.25+). When this is enabled, nginx will pad the size of the response body to a minimum of 512 bytes, for responses with a status code above or equal to 400.

The padding prevents the activation of "friendly" HTTP error pages in MSIE and Chrome, so as to not hide the more-informative error pages from the server.

Edit section: msie_refresh msie_refresh

syntax: msie_refresh [on|off]

default: msie_refresh off

context: http, server, location

This directive allows or forbids issuing a refresh instead of doing a redirect for MSIE.

Edit section: open_file_cache open_file_cache

syntax: open_file_cache max = N [inactive = time] | off

default: open_file_cache off

context: http, server, location

The directive sets the cache activity on. These information can be stored:

  • Open file descriptors, information with their size and modification time;
  • Information about the existence of directories;
  • Error information when searches for a file - no file, do not have rights to read, etc. See also open_file_cache_errors

Options directive:

  • max - specifies the maximum number of entries in the cache. When the cache overflows, the longest-used items(LRU) will be removed;
  • inactive - specifies the time when the cached item is removed, if it has not been downloaded during that time, the default is 60 seconds;
  • off - prohibits the cache activity.

Example: 

 open_file_cache max=1000 inactive=20s; 
 open_file_cache_valid    30s; 
 open_file_cache_min_uses 2;
 open_file_cache_errors   on;

Edit section: open_file_cache_errors open_file_cache_errors

syntax: open_file_cache_errors on | off

default: open_file_cache_errors off

context: http, server, location

The directive specifies to cache errors or not when searching a file.

Edit section: open_file_cache_min_uses open_file_cache_min_uses

syntax: open_file_cache_min_uses number

default: open_file_cache_min_uses 1

context: http, server, location

The directive defines the minimum use number of a file within the time specified in the directive parameter inactive in open_file_cache. ?If use more than the number, the file descriptor will remain open in the cache.

Edit section: open_file_cache_valid open_file_cache_valid

syntax: open_file_cache_valid time

default: open_file_cache_valid 60

context: http, server, location

The directive specifies the time when need to check the validity of the information about the item in open_file_cache.

Edit section: optimize_server_names optimize_server_names

syntax: optimize_server_names [ on|off ]

default: optimize_server_names on

context: http, server

Directive activates or deactivates optimization of host name checks for name-based virtual servers.

In particular, the check influences the name of the host used in redirects. If optimization is on, and all name-based servers listening on one address:port pair have identical configuration, then names are not checked during request execution and redirects use first server name.

If redirect must use host name passed by the client, then the optimization must be turned off.

Note: this directive is deprecated in nginx 0.7.x, use server_name_in_redirect instead.

Edit section: port_in_redirect port_in_redirect

syntax: port_in_redirect [ on|off ]

default: port_in_redirect on

context: http, server, location

Directive allows or prevents port indication in redirects handled by nginx.

If port_in_redirect is on, then Nginx will not add the port in the url when the request is redirected.

Edit section: recursive_error_pages recursive_error_pages

syntax: recursive_error_pages [on|off]

default: recursive_error_pages off

context: http, server, location

recursive_error_pages enables or disables following a chain of error_page directives.

Edit section: resolver resolver

syntax: resolver address

default: no

context: http, server, location

TODO: Description

Edit section: resolver_timeout resolver_timeout

syntax: resolver_timeout time

default: 30

context: http, server, location

Resolver timeout in seconds.

Edit section: root root

syntax: root path

default: root html

context: http, server, location, if in location

root specifies the document root for the requests. For example, with this configuration 

location  /i/ {
  root  /spool/w3;
}

A request for "/i/top.gif" will return the file "/spool/w3/i/top.gif". You can use variables in the argument.

note: Keep in mind that the root will still append the directory to the request so that a request for "/i/top.gif" will not look in "/spool/w3/top.gif" like might happen in an Apache-like alias configuration where the location match itself is dropped. Use the alias directive to achieve the Apache-like functionality.

Edit section: satisfy_any satisfy_any

syntax: satisfy_any [ on|off ]

default: satisfy_any off

context: location

Directive solves access with at least one successful checking, executed by modules NginxHttpAccessModule or NginxHttpAuthBasicModule: 

location / {
  satisfy_any  on;
  allow  192.168.1.0/32;
  deny   all;
  auth_basic            "closed site";
  auth_basic_user_file  conf/htpasswd;
}

Edit section: send_timeout send_timeout

syntax: send_timeout the time

default: send_timeout 60

context: http, server, location

Directive assigns response timeout to client. Timeout is established not on entire transfer of answer, but only between two operations of reading, if after this time client will take nothing, then nginx is shutting down the connection.

Edit section: sendfile sendfile

syntax: sendfile [ on|off ]

default: sendfile off

context: http, server, location

Directive activate or deactivate the usage of sendfile().

Edit section: server server

syntax: server {...}

default: no

context: http

Directive assigns configuration for the virtual server.

There is no separation of IP and name-based (the Host header of the request) servers.

Instead, the directive listen is used to describe all addresses and ports on which incoming connections can occur, and in directive server_name indicate all names of the server.

Edit section: server_name server_name

syntax: server_name name [... ]

default: server_name hostname

context: server

This directive performs two actions:

  • Compares the Host header of the incoming HTTP request against the server { ... } blocks in the Nginx configuration files and selects the first one that matches. This is how virtual servers are defined. Server names are processed in the following order:
  1. full, static names
  2. names with a wildcard at the start of the name — *.example.com
  3. names with a wildcard at the end of the name — www.example.*
  4. names with regular expressions
If there is no match, a server { ... } block in the configuration file will be used based on the following order:
  1. the server block with a matching listen directive marked as default
  2. the first server block with a matching listen directive (or implicit listen 80;)

Example: 

server {
  server_name   example.com  www.example.com;
}

The first name becomes the basic name of server. By default the name of the machine (hostname) is used.

It is possible to use "*" for replacing the first or the last part of the name: 

server {
  server_name   example.com  *.example.com  www.example.*;
}

The first two of the above names (example.com and *.example.com) can be combined into one: 

server {
  server_name  .example.com;
}

It is also possible to use regular expressions in server names, prepending the name with a tilde "~" like so: 

server {
  server_name   www.example.com   ~^www\d+\.example\.com$;
}


The basic name of server is used in an HTTP redirects, if no Host header was in client request or that header does not match any assigned server_name. You can also use just "*" to force Nginx to use the Host header in the HTTP redirect (note that "*" cannot be used as the first name, but you can use a dummy name such as "_" instead): 

server {
  server_name example.com *;
}
server {
  server_name _ *;
}

Note that this has changed in 0.6.x and is now: 

server {
  server_name _;
}

Since nginx 0.7.12, an empty server name is supported, to catch the requests without "Host" header: 

server {
  server_name "";
}

Since nginx 0.8.25 named captures can be used in server_name: 

server {
  server_name   ~^(www\.)?(?<domain>.+)$;
  location / {
    root  /sites/$domain;
  }
}

Some older versions of PCRE may have issues with this syntax. If any problems arise try this following syntax: 

server {
  server_name   ~^(www\.)?(?P<domain>.+)$;
  location / {
    root  /sites/$domain;
  }
}

Edit section: server_name_in_redirect server_name_in_redirect

syntax: server_name_in_redirect on|off

default: server_name_in_redirect on

context: http, server, location

If server_name_in_redirect is on, then Nginx will use the first value of the server_name directive for redirects. If server_name_in_redirect is off, then nginx will use the requested Host header.

Edit section: server_names_hash_max_size server_names_hash_max_size

syntax: server_names_hash_max_size number

default: server_names_hash_max_size 512

context: http

The maximum size of the server name hash tables. For more detail see the description of tuning the hash tables in Nginx Optimizations.

Edit section: server_names_hash_bucket_size server_names_hash_bucket_size

syntax: server_names_hash_bucket_size number

default: server_names_hash_bucket_size 32/64/128

context: http

Directive assigns the size of basket in the hash-tables of the names of servers. This value by default depends on the size of the line of processor cache. For more detail see the description of tuning the hash tables in Nginx Optimizations.

Edit section: server_tokens server_tokens

syntax: server_tokens on|off

default: server_tokens on

context: http, server, location

Whether to send the Nginx version number in error pages and Server header.

Edit section: tcp_nodelay tcp_nodelay

syntax: tcp_nodelay [on|off]

default: tcp_nodelay on

context: http, server, location

This directive allows or forbids the use of the socket option TCP_NODELAY. Only included in keep-alive connections.

You can read more about the TCP_NODELAY socket option here.

Edit section: tcp_nopush tcp_nopush

syntax: tcp_nopush [on|off]

default: tcp_nopush off

context: http, server, location

This directive permits or forbids the use of the socket options TCP_NOPUSH on FreeBSD or TCP_CORK on Linux. This option is only available when using sendfile.

Setting this option causes nginx to attempt to send it's HTTP response headers in one packet on Linux and FreeBSD 4.x

You can read more about the TCP_NOPUSH and TCP_CORK socket options here.

Edit section: try_files try_files

syntax: try_files file1 [file2 ... filen] fallback

default: none

context: location

This directive tells Nginx to test for each file's existence, and use the first found file as the URI. If none of the files are found, then the location fallback is called ("fallback" can be any name). fallback is a required parameter. It can be a named location or any guaranteed URI.

Example: 

location / {
  try_files index.html index.htm @fallback;
}
 
location @fallback {
  root /var/www/error;
  index index.html;
}

Edit section: types types

syntax: types {...}

context: http, server, location

Directive assigns the correspondence of expansion and MIME-types of answers. To one MIME- type can correspond several expansions. By default it is used these correspondences: 

types {
  text/html    html;
  image/gif    gif;
  image/jpeg   jpg;
}

The sufficiently complete table of mappings is included and is located in the file conf/mime.types.

So that for that determined location's for all answers would reveal MIME- type application/octet-stream, it is possible to use the following: 

location /download/ {
  types         { }
  default_type  application/octet-stream;
}

Edit section: Variables Variables

The core module supports built-in variables, whose names correspond with the names of variables in Apache.

First of all, there are the variables, which represent the lines of the title of the client request, for example, $http_user_agent, $http_cookie, and so forth.

Furthermore, there are other variables:

Edit section: $arg_PARAMETER $arg_PARAMETER

This variable contains the value of the GET request variable PARAMETER if present in the query string

Edit section: $args $args

This variable is equal to arguments in the line of request;

Edit section: $binary_remote_addr $binary_remote_addr

The address of the client in binary form;

Edit section: $body_bytes_sent $body_bytes_sent

(undocumented)

Edit section: $content_length $content_length

This variable is equal to line Content-Length in the header of request;

Edit section: $content_type $content_type

This variable is equal to line Content-Type in the header of request;

Edit section: $cookie_COOKIE $cookie_COOKIE

The value of the cookie COOKIE;

Edit section: $document_root $document_root

This variable is equal to the value of directive root for the current request;

Edit section: $document_uri $document_uri

The same as $uri.

Edit section: $host $host

This variable is equal to line Host in the header of request or name of the server processing the request if the Host header is not available.

This variable may have a different value from $http_host when the Host input header is absent or has an empty value.

Edit section: $http_HEADER $http_HEADER

The value of the HTTP header HEADER when converted to lowercase and with 'dashes' converted to 'underscores', e.g. $http_user_agent, $http_referer...;

Edit section: $is_args $is_args

Evaluates to "?" if $args is set, "" otherwise.

Edit section: $limit_rate $limit_rate

This variable allows limiting the connection rate.

Edit section: $query_string $query_string

The same as $args.

Edit section: $remote_addr $remote_addr

The address of the client.

Edit section: $remote_port $remote_port

The port of the client;

Edit section: $remote_user $remote_user

This variable is equal to the name of user, authenticated by the Auth Basic Module;

Edit section: $request_filename $request_filename

This variable is equal to path to the file for the current request, formed from directives root or alias and URI request;

Edit section: $request_body $request_body

This variable(0.7.58+) contains the body of the request. The significance of this variable appears in locations with directives proxy_pass or fastcgi_pass.

Edit section: $request_body_file $request_body_file

Client request body temporary filename;

Edit section: $request_completion $request_completion

(undocumented)

Edit section: $request_method $request_method

This variable is equal to the method of request, usually GET or POST.

Before and including 0.8.20, this variable always evaluates to the method name of the main request, not the current request if the current request is a subrequest.

Edit section: $request_uri $request_uri

This variable is equal to the *original* request URI as received from the client including the args. It cannot be modified. Look at $uri for the post-rewrite/altered URI.

Edit section: $scheme $scheme

The HTTP scheme (i.e. http, https). Evaluated only on demand, for example: 

rewrite  ^(.+)$  $scheme://example.com$1  redirect;

Edit section: $server_addr $server_addr

Equal to the server address. As a rule, for obtaining the value of this variable is done one system call. In order to avoid system call, it is necessary to indicate addresses in directives listen and to use parameter bind.

Edit section: $server_name $server_name

The name of the server.

Edit section: $server_port $server_port

This variable is equal to the port of the server, to which the request arrived;

Edit section: $server_protocol $server_protocol

This variable is equal to the protocol of request, usually this HTTP/1.0 or HTTP/1.1.

Edit section: $uri $uri

This variable is equal to current URI in the request (without arguments, those are in $args.) It can differ from $request_uri which is what is sent by the browser. Examples of how it can be modified are internal redirects, or with the use of index.

Edit section: References References

Original Documentation

Retrieved from "http://wiki.nginx.org/NginxHttpCoreModule"