Forum: NGINX Separate Log for Robot Page Access

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.

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 ;
>         }

http://wiki.nginx.org/IfIsEvil

This won't work, see third example.

Maxim Dounin

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 ;
        }

<editorial>
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.
</editorial>

--
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.

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.

> <editorial>
> 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 Dounin

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.

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 Dounin

On Sat, Feb 6, 2010 at 2:32 AM, Wohbah <2947779@deadaddress.com> 
trolled:
> <editorial>
> 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:
http://www.cs.chalmers.se/~oloft/Papers/wm96/wm96.html . 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.
> </editorial>

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

Thanks,
-- Merlin