Hacker News Reader

Comment by merlincorey | Hacker News Reader

This is a cool little project showcasing some of NginX's lesser known modules in action.

However, I have one nitpick.

The caching server's main location is a bit of a cargo-cult unoptimization. They have specified:

    location ^/(.+)$ {

When the equivalent:

    location / {

Is shorter, clearer, and does not incur a regular expression capture on every request that is never used.

View on HN

I (I'm not the author) shamefully do some cargo cult Nginx because I don't understand how the location matching really works.

My ideal web server would have a configuration that resembles a decision procedure in a programming language, so I can have a mental model for what makes it choose one route over the others, and how settings are combined, etc.

Somehow Nginx repeatedly makes me and my coworkers very confused—are we crazy or just mildly incompetent? Should I read an Nginx book?

(One time I wanted to do something fairly straightforward, I think using a conditional inside some block, and when I looked in the manual it warned very strongly that this might cause segmentation faults. I was like WTF?)

NginX has come a long way and so has the documentation: http://nginx.org/en/docs/

I highly recommend this document to start, which describes how NginX processes a request: http://nginx.org/en/docs/http/request_processing.html

For getting the mental model right, you have to understand that NginX configuration is declarative, like SQL or PROLOG. That means as opposed to an imperative or procedural language you might be more familiar with, in NginX you describe "what" you want to have handled, not "how" and NginX worries about the "how" under the hood, for the most part.

Of course like any abstraction it sometimes breaks and leaks, but this is practical software we're talking about. One specific big headache for people is when using "if" in NginX, which is a decidedly imperative construct! As such you do have to tread lightly with it; observe If Is Evil: https://www.nginx.com/resources/wiki/start/topics/depth/ifis...

The difference is that the last one also matches requests to "/", while the regex ensures that there is at least a single character after the "/".

That allows "/" to be used for other purposes, e.g. redirecting to the main page of the site, or displaying a nice error page. (However, in this case it simply shows the default Debian Nginx installation page: http://m.charlesleifer.com/ )

For that use case, I would recommend two locations like so:

    location = / {
      # Just whatever happens for "/" requests goes here
    }
    
    location / {
      # Every other requests ends up here
    }

Actually, Nginx are way ahead of you. Here's the way to handle that.

    location = / { [ configuration A ] }

    location / { [ configuration B ] }

To learn more about this, I recommend http://nginx.org/en/docs/http/ngx_http_core_module.html

The Nginx docs are not always great but they are far more correct than most blog posts about Nginx so that is why I have turned to use only the official docs when I have a question about how to do something with Nginx.

Thank you, I've updated the post.

Reply on news.ycombinator.com