Book Image

Nginx HTTP Server - Second Edition

By : Clement Nedelcu
Book Image

Nginx HTTP Server - Second Edition

By: Clement Nedelcu

Overview of this book

<p>Nginx is a lightweight HTTP server designed for high-traffic websites, with network scalability as the primary objective. With the advent of high speed Internet access, short loading times and fast transfer rates have become a necessity. This free, open source solution will either come as a full replacement of other software such as Apache, or stand in front of your existing infrastructure to improve its overall speed.</p> <p>"Nginx HTTP Server - Second Edition" provides a detailed guide to setting up Nginx in different ways that correspond to actual production situations: as a standalone server, as a reverse proxy, interacting with applications via FastCGI and more. In addition, the complete directive reference will be your best friend at all stages of the configuration and maintenance processes.</p> <p>This book is the perfect companion for both Nginx beginners and experienced administrators. For beginners, it will take you through the complete process of setting up this lightweight HTTP server on your system and configuring its various modules to get it to do exactly what you need, in a fast and secure way. For more experienced administrators, this book provides different angles of approach that can help you make the most of your current infrastructure. Nginx can be employed in many situations, whether you are looking to construct an entirely new web-serving architecture or simply want to integrate an efficient tool to optimize your site loading speeds.</p> <p>This book takes you through the setup and configuration of Nginx by detailing every step of the way, from downloading to configuring your server in a selection of common architectures.</p>
Table of Contents (17 chapters)
Nginx HTTP Server Second Edition
Credits
About the Author
About the Reviewers
www.PacktPub.com
Preface
Directive Index
Index

If block issues


In some situations, if not most, you should avoid using if blocks. There are two main issues occurring, regardless of the Nginx build you are using.

Inefficient statements

There are some cases where if is used inappropriately, in a way that risks saturating your storage device with useless checks:

location / {
    # Redirect to index.php if the requested file is not found
    if (!-e $request_filename) {
       rewrite ^ index.php last;
    }
}

With such a configuration, every single request received by Nginx will trigger a complete verification of the directory tree for the requested filename, thus requiring multiple storage disk access system calls. If you test /usr/local/nginx/html/hello.html, Nginx will check /, /usr, /usr/local, /usr/local/nginx, and so on. In any case, you should avoid resorting to such a statement. For example, by filtering the file type beforehand (for instance, by making such a check, only if the requested file matches specific extensions):

location / {
    # Filter file extension first
    if ($request_filename !~ "\.(gif|jpg|jpeg|png)" {
       break;
    }
    if (!-f $request_filename) {
       rewrite ^ index.php last;
    }
}

Unexpected behavior

The if block should ideally be employed for simple situations, as its behavior might be surprising in some cases. Apart from the fact that if statements cannot be nested, the following situations may present issues:

# Two consecutive statements with the same condition:
location / {
    if ($uri = "/test.html") {
       add_header X-Test-1 1;
       expires 7;
    }
    if ($uri = "/test.html") {
       add_header X-Test-1 1;
    }
}

In this case, the first if block is ignored and only the second one is processed. However, if you insert a Rewrite module directive in the first block, such as rewrite, break, or return, the block will be processed and the second one will be ignored.

There are many other cases where the use of if causes problems:

  • Having try_files and if statements in the same location block is not recommended as the try_files directive will, in most cases, be ignored.

  • Some directives are theoretically allowed within the if block but can create serious issues, for instance, proxy_pass and fastcgi_pass. You should keep those within location blocks.

  • You should avoid using if blocks within a location block that captures regular expression patterns from its modifier.

The origin of these problems comes from the fact that while the Nginx configuration is established in a declarative language, directives from the Rewrite module such as if, rewrite, return, or break make it look like actual scripting. In general, you should try to avoid using directives from other modules within if blocks as much as possible.