Configuration Primer


#1

Does there exist an english introduction to NginX config ‘programming’?

I have found various example configurations, both simplistic and ‘full
featured’.

I have found the list of modules on the wiki, and the command-centric
documentation they supply. (Though I wish even this were more in-
depth. For example, what is the regex syntax allowed for the rewrite
command? PCRE? Posix classes? Lookaheads/lookbehinds?)

What I’m missing is an overview of how configurations really work.
With the ability to set variables, scoping, break directives and
rewrite commands like last/break/redirect/permanent, it’s more like a
programming language than a set of parameters. Various questions this
has raised in my mind regarding the sort of information I’m looking for:
What is the ‘flow’ of execution?
When you ‘break’, what scope/context are you stopping the directives in?
When all is said and done, what is being returned?
Can I chain multiple rewrites? Does a rewrite affect all kinds of
later matches (e.g. ‘if’ or ‘location’)?

While answers to the above specific questions would almost certainly
help me string a few islands of knowledge together, I’m hoping someone
knows of a guide already written. Something that starts at NginX
Config Theory 101 (not super-simple examples, but instead something
like stepping through the procedure of matching a request against a
config file from start to finish) and then covers things like Virtual
Hosts and Virtual Directories and so on.

Any chance it exists?


#2

On Thu, Feb 19, 2009 at 23:09, Gavin K. removed_email_address@domain.invalid wrote:

Does there exist an english introduction to NginX config ‘programming’?

None, AFAIK. I had the same problem a few months ago when I switched
to nginx. I ended up learning by example, getting nginx to do what I
wanted, then forgetting about it.

This is probably the reason nobody wrote a clear, academic, intro to
nginx configuration.

Dan


#3

On Thu, Feb 19, 2009 at 23:09, Gavin K. wrote:

Does there exist an english introduction to NginX config ‘programming’?

None, AFAIK. I had the same problem a few months ago when I switched
to nginx. I ended up learning by example, getting nginx to do what I
wanted, then forgetting about it.

This is probably the reason nobody wrote a clear, academic, intro to
nginx configuration.

http://wiki.nginx.org/NginxConfiguration
http://wiki.nginx.org/NginxModules

I don’t get what else are you expecting?
I mean there are basic samples / advanced configurations / specific
cases
covered. On each ( http://wiki.nginx.org/NginxFullExample ) statement,
option you can click on and see what it actually means / does.

Of course the more documentation the better then again saying there is
none
at all is wrong.

rr


#4

On Wed, Mar 18, 2009 at 11:33:03AM +0200, Reinis R. wrote:

http://wiki.nginx.org/NginxConfiguration
http://wiki.nginx.org/NginxModules

I don’t get what else are you expecting?
I mean there are basic samples / advanced configurations / specific cases
covered. On each ( http://wiki.nginx.org/NginxFullExample ) statement,
option you can click on and see what it actually means / does.

Of course the more documentation the better then again saying there is none
at all is wrong.

This is a reference and some cookbook recepts but not introdution.
I can write draft description of request processing from confuguration
point of view but without these ugly rewrites as want to change them.


#5

2009/3/18 Igor S. removed_email_address@domain.invalid:

This is a reference and some cookbook recepts but not introdution.
I can write draft description of request processing from confuguration
point of view but without these ugly rewrites as want to change them.

When you say “ugly rewrites” what do you mean?

IMHO, nginx is pretty easy to pick up. At first when I saw the syntax
I thought “oh no, another config file to learn” but it is pretty damn
simple.

My biggest issue is with location blocks. It is still confusing and
gets annoying on sites requiring multiple location blocks, especially
with regexps and determining the right ^~ or *~ etc.

Other than that, a few tweaks to allow things like error_log at -any-
level not just global and server but even inside conditionals would be
neat…

But I’m wondering what you meant by that. You have some code you don’t
like in nginx that you want to rewrite? If so, what? Or the “rewrite”
directive itself and such is a nasty thing. I like to hear the plans
and news about nginx (call me an nginx fanboy now) - even a roadmap
would be cool too (I think I’ve seen bits and pieces in the past) of
what at least you plan on changing/adding, and of course if other
people do third party modules or patch things in the core that can
only enhance it quicker…


#6

My biggest issue is with location blocks. It is still confusing and
gets annoying on sites requiring multiple location blocks, especially
with regexps and determining the right ^~ or *~ etc.

The biggest issue in my mind is the way nginx doesnt merge/inherit (
http://wiki.nginx.org/NginxHttpCoreModule#location ) the
options for different location blocks if there are more than one that
matches.
It can be handy sometimes but usually it has created me more issues and
some nasty workarrounds than helped.

Like sometimes there is the need to have:

location ~ ^/zzz { … }

But if you have the default location ~ .php$ { … } defined before

It means that the /zzz/some.php requests wont use any options you
defined in the config.

I have whined about this (and also about global location feature in the
http{} scope) to Igor some time ago but he was sceptical at
that time :wink:

rr


#7

Having ‘elseif’ / ‘else’ blocks as well as ‘if’ would be handy too.
It’s obviously possible with lots of ‘if’ statements, but isn’t the most
efficient way of doing things.

Marcus.


#8

On Wed, 2009-03-18 at 12:38 -0700, mike wrote:

i don’t like having to do

location .php {
stuff
}

location /foo {
auth basic stuff
… and i have to do the php stuff again
}

Couldn’t you just do:

include /etc/nginx/php.conf;

location /foo {
auth basic stuff
include /etc/nginx/php.conf;
}

Regards,
Cliff


#9

i don’t like having to do

location .php {
stuff
}

location /foo {
auth basic stuff
… and i have to do the php stuff again
}

i guess there’s no real way around it, really. it’s just a gripe i
have, i suppose. perhaps some way of inheriting all locations globally
first and then doing second level, then third level, etc…


#10

yes but each virtual host may have different php configs. so then i’m
supporting a ton of includes :slight_smile: