Separate Log for Robot Page Access

Server NGINX
1

To record robots in another log I have a boolean $is_robot. The
variable is
set correctly. But I can’t use it. (nginx version 0.765-1)

Why can I do
if ( … ) { … access_log off; … }
but not
if ( … ) { … access_log /var/log/nginx/robots.log; … }

When a robot visits, it gets error 500. No web page. Must I duplicate
every location to change access_log settings? Here is the topmost one:

    location / {
      access_log  /var/log/nginx/access.log;

      ...much stuff I do not like duplicating, several lines...

      if ( $is_robot ~ T ) {
        access_log  /var/log/nginx/robots.log;
      }
      try_files /maintenance.html $uri.html @phptry ;
    }

–
View this message in context:
http://n2.nabble.com/Separate-Log-for-Robot-Page-Access-tp4524448p4524448.html
Sent from the nginx mailing list archive at Nabble.com.

2

Hello!

On Sat, Feb 06, 2010 at 12:31:41AM -0800, Wohbah wrote:

every location to change access_log settings? Here is the topmost one:
Yes, once you want to do something different you have to create
another location. Directive “if” does this implicitly, but it
fails to do it correctly in many cases.

    location / {
      access_log  /var/log/nginx/access.log;
      
      ...much stuff I do not like duplicating, several lines...

      if ( $is_robot ~ T ) {
        access_log  /var/log/nginx/robots.log;
      }
      try_files /maintenance.html $uri.html @phptry ;
    }

This won’t work, see third example.

Maxim D.

3

What about a variable? There is no conditional in the location block.

    set $logchoice       /var/log/nginx/access.log;
    if ( $is_robot ~ T ) {
        set $logchoice   /var/log/nginx/robots.log;
    }

    location / {
      access_log  $logchoice;
      ...
      try_files /maintenance.html $uri.html @phptry ;
    }
Conditionals are fundamental. Imagine a CPU without one. Lack of conditionals makes makes me ill. One of the few things not to like about nginx. Mabye *location* is evil ... but not conditionals. If nginx conflicts with computer science, the flaw is not in compsci.

Now, avoiding “if” over labor effort, OK, that is a legitimate and good
reason! In fact, it’s a much better reason than denying fundamental
compsci.

But it means ugly software. Nginx foists complexity onto user .conf
files.
Which, as you say, work inconsistently (more ugliness).

Still, thank you nginx for wonderful software. It sometimes seems like
a
baby with a rash, you just want it to heal so there’s less diaper
changing.

–
View this message in context:
http://n2.nabble.com/Separate-Log-for-Robot-Page-Access-tp4524448p4524797.html
Sent from the nginx mailing list archive at Nabble.com.

4

Hello!

On Sat, Feb 06, 2010 at 02:32:23AM -0800, Wohbah wrote:

      ...
      try_files /maintenance.html $uri.html @phptry ;
    }

This will work as expected though it implies overhead of
calculating logpaths and opening them for every request. You may
consider using “if” with “rewrite … last” or “return …” in
location blocks instead.

Conditionals are fundamental. Imagine a CPU without one. Lack of conditionals makes makes me ill. One of the few things not to like about nginx. Mabye *location* is evil ... but not conditionals. If nginx conflicts with computer science, the flaw is not in compsci.

CPU allows only one thing to be done conditionally: jump to
another instruction address. This is exacly what is now may be
done safely in nginx: you may jump to another location block.

And, just in case you haven’t noticed it: location is
conditional directives. They allow you to select configuration
depending on request uri.

The topic I pointed you to just explains one simple thing: “if”
directive in nginx as currently implemented doesn’t do what you
expect and should be avoided. The only safe things which may be
done are specially outlined.

Maxim D.

5

Hello!

On Sat, Feb 06, 2010 at 04:45:41PM -0800, Wohbah wrote:

It did work. But I had to use

-p “/”

on the nginx command line. Otherwise path vars got broken; nginx forced a
prefix.

nginx adds prefix to every path which doesn’t start with ‘/’
during configuration parsing (i.e. before variables are evaluated,
which happens only during request processing).

If you are planning to use absolute paths constructed with
variables in directives which take paths and have non-null prefix
you should indicate absolute path by placing leading ‘/’, e.g.

root /$full_path;

Not sure this is documented somewhere though.

[…]

Maxim D.

6

Maxim,

It did work. But I had to use

-p “/”

on the nginx command line. Otherwise path vars got broken; nginx forced
a
prefix.

Suggestion: a built-in var, “$prefix_path” that is read/write in
nginx.conf. (Then no system files like rc.d’s need change. System
files
vary by OS.)

CPUs do more conditionals than branch; set register flags, increment
counters, shuffle memory. But why enforce “assembly language” style?
Offer
high-level constructs.

About “evil”: In programming languages, everybody knows that GOTO is
EVIL.
Rewrite-jumping from location to location is GOTO.

Location is not even that general, because it has semantics. A CPU
branch
does not.

Nginx is “path-oriented” software. Of course “location” is a
conditional.
It just isn’t general. Nginx calls generality “evil”. Most programmers
consider it a mark of GOOD and CAPABLE software.

What I need is a very simple concept: branch log files depending on
user
agent, not web page request.

It should not involve location blocks, because web page location is
identical. Only user agent differs.

It shouldn’t be hard. It shouldn’t carry overhead more than a trivial
flag
check. If it is, and if it does, then nginx has room to improve.

True, GOTO-style assembly-like language can do anything - but people
long
ago built better tools. In nginx terms, duplicating every location
block
just to change one line in each is ugly and confusing (semantically
wrong).

I just tired of sifting people from robots and decided to move robots to
their own log. Nothing fancy.

OK, thank you. Nginx is still the best, it just needs to grow…I’m
confident it will.

–
View this message in context:
http://n2.nabble.com/Separate-Log-for-Robot-Page-Access-tp4524448p4527589.html
Sent from the nginx mailing list archive at Nabble.com.

7

On Sat, Feb 6, 2010 at 2:32 AM, Wohbah [email protected]
trolled:

Conditionals are fundamental. Imagine a CPU without one.

Maxim already pointed out that the only place there are conditionals
in processors are in the JXX opcodes. I just like repeating the
obvious.

Lack of
conditionals makes makes me ill. One of the few things not to like about
nginx.

There’s conditionals all over! They just prefer to be declarative
rather than imperitive.

Mabye location is evil … but not conditionals. If nginx
conflicts with computer science, the flaw is not in compsci.

Not in our experience. We might actually have been using this
software a few times over the years, too.

Now, avoiding “if” over labor effort, OK, that is a legitimate and good
reason! In fact, it’s a much better reason than denying fundamental
compsci.

Fundamental computer science concepts indeed! You should get your
money back if you are a computer science student and only learned the
imperative paradigm. I refer you to this paper:
A Note on Declarative Programming Paradigms and the Future of Definitional Programming . Let’s have an
excerpt:

"
The basic property of a declarative programming language is that a
program is a theory in some suitable logic. This property immediately
gives a precise meaning to programs written in the language. From a
programmers point of the the basic property is that programming is
lifted to a higher level of abstraction. At this higher level of
abstraction the programmer can concentrate on stating what is to be
computed, not necessarily how it is to be computed. In Kowalski’s
terms where algorithm = logic + control, the programmer gives the
logic but not necessarily the control.
"

In NginX, you tell it WHAT you want to do, and it handles the HOW.

But it means ugly software. Nginx foists complexity onto user .conf files.
Which, as you say, work inconsistently (more ugliness).

This statement is opinion of the author, who is unfamiliar with nginx
configuration language and higher level concepts such as declarative
programming in general. This author personally finds nginx to be
beautiful software that allows him to make simple configurations
relative to other httpd’s.

Still, thank you nginx for wonderful software. It sometimes seems like a
baby with a rash, you just want it to heal so there’s less diaper changing.

Excuse the vernacular but it fits perfectly… NginX rarely takes a
shit for me, mate!

Thanks,
– Merlin