Errata

I've skimmed over most of the book, and don't recall seeing anything substantive about logging. Is there a planned section or chapter on configuring what information goes to a log file, where the log file lives, how to read the log file entries, etc.? Or is this not really a concern, e.g., because it's not that complicated or not that configurable?

3rd para of this section states that regex blocks are processed in order of declaration. Not until bottom of next page are we told that regexes get matched after prefix locations (and, presumably, exact match locations).

Might be nice to spell out the priority rules all in one place, rather than piecemeal.

Since this section leans heavily on regexes, it might be nice to provide a pointer to a reference or learning site about them. At least mention what flavor of regex gets used.

"Because regular expressions are matched after the prefix locations, if there is a request URI for /foobar/images/dog.gif, the regular expression block will always be used."

I find this confusing. If prefix locations get matched before regex locations, that implies that `/foobar/images/dog.gif` should get matched to the prefix location `/foobar/images`.

This, at least, is the mental model I formed when I read, earlier, that "Location blocks with an exact match modifier are the first blocks to be checked for a match and will terminate the search and immediately be selected for use." In other words, what I have read up to this point implies that the order of match attempts is fixed, and as soon as a match is found, the search terminates.

But here, apparently, the order of selection is done in the inverse of the order of matching (because here the regex location gets checked last and therefore gets used).

So either this sentence is not right, or there is something not explicit about how the locations get matched-- for example, that all possible matches are considered, and the most recent one (or most explicit one) gets selected.

Broadly looking for clarification of this point.

This section definitely addresses my questions about priority (if I could edit my earlier comments, I would combine all of them).

However, I think this section comes too late, given the confusing before/after language that I pointed out in a previous comment.

After reading this big, I think I would suggest changing that paragraph at the bottom of p.36 to state, correctly, that regex locations are matched _before_ prefix locations.

In addition, I think the priority list could be made more clear by distinguishing between simple, unadorned prefix blocks, and
those with the ^~ modifier. Then one could simply give the priorities as:
1. Exact match.
2. Prefix blocks with ^~ modifier, in order of specificity.
3. Regex blocks, in sequential order.
4. Prefix blocks without ^~ modifier, in order of specificity (and one could invent some terminology, like, say, "unadorned" or "simple" prefix blocks, to cement the distinction conferred by the ^~ modifier).

That seems more straightforward than the current ordered list, in which step #2 describes a mostly-deferred matching against all the prefix blocks, with step 2a to describe immediate action and step 4 to describe deferred action. Even if that accurately describes what nginx does "under the covers", that's just an implementation detail.

Alternately, you might consider moving this section up a little earlier (say, to appear between the section on "Basic Location Blocks" and that on Regex Location Blocks"). It would probably be OK to read about the priorities up-front and all at once, with a promise to explain the regex ones shortly. Although I don't think this is really necessary, provided the "after" discussion gets cleaned up a bit.

Finally, in this section I would separate out the table from the list. Graphically, I think enclosing the table in the box looks a little busy. So I would consider writing the section as a straightforward description of the algorithm, with a reference to a stand-alone table to remind readers what the various location blocks look like.

The location block uses a case-sensitive regex:
`location ~ script.php {...`

The following text states that this matches a single PHP script, script.php.

If the intent is to match a single script, it isn't clear why one would not use an exact match location block, or a basic prefix location block.

"the following chapters on Load Balancing and FastCGI"

The chapter on FastCGI precedes this one, rather than following it.

The configuration file is getting more and more complicated. If I had a blank location block, like the one shown in the example here, I would certainly want to add comments in the config file to remind myself what's going on:
location /assets {

}

I don't remember reading anything about how to add comments to a configuration file.

Searching the PDF for the word "comment" turns up an instance on page 74 ("The reason that you’d use down to remove a server instead of commenting it out..."). This implies it is possible to have comments in the config file. And the example on page 81 (right before "Weighted Servers") implies one uses a C-style # to comment through the end of the line.

It would be nice to mention how to do this, in Chapter 2.

"...check for the existence of maintenance.html, which will short-circuit forwarding the request to the upstream if it exists."

This is confusing for two reasons.

First, to the upstream what? I assume this means to the upstream server, meaning WEBrick in the running example. And that makes sense given that "upstream" is a keyword in the config file. However the phrase "the upstream" has not been defined yet. I see from the Table of Contents that "the upstream" seems to be a term of art, but to my best memory it hasn't been introduced as a term yet. I would try to make a point that "the upstream" is a way of talking about the proxy tagged as "upstream" in the config file, before casually using it this way. Alternately, typeset "upstream" so that it's clearly identified as a keyword.

Second, and more important, I believe the "it" here refers to `maintenance.html`. That is, forwarding the request to the upstream will get short-circuited if `main.html` exists. The problem here is that "the upstream" intervenes between "maintenance.html" and "it", so "it" becomes identified with "the upstream" rather than with the file.

A suggested rewrite would be "check for the existence of maintenance.html. Then if maintenance.html exists, nginx will not forward the request to the upstream server."

"If we were [to] set the root one level lower, for example, to /path/to/application"

The example of setting the path the `path/to/application` presumably stands in contrast to the root set in Example 4-3, namely, `path/to/application/public`.

Is it conventional to describe directory `a/b/c` as "one level lower" than directory `a/b/c/d`? I have always heard that relationship described as "one level up" in the directory structure, and hence I think of `a/b/c` as "higher" than `a/b/c/d`.