# Separate Log for Robot Page Access **URL:** \ **Category:** NGINX\ **Created:** [February 6, 2010, 9:47am UTC](https://www.ruby-forum.com/t/separate-log-for-robot-page-access/183021 "2010-02-06T09:47:52Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Wohbah](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/e36b37/32.png) [@Wohbah](https://www.ruby-forum.com/u/Wohbah)\ **Post date:** [February 6, 2010, 9:47am UTC](https://www.ruby-forum.com/t/separate-log-for-robot-page-access/183021/1 "2010-02-06T09:47:52Z")
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](http://n2.nabble.com/Separate-Log-for-Robot-Page-Access-tp4524448p4524448.html) Sent from the nginx mailing list archive at [Nabble.com](http://Nabble.com). ---
**Author:** ![Wohbah](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/e36b37/32.png) [@Wohbah](https://www.ruby-forum.com/u/Wohbah)\ **Post date:** [February 6, 2010, 10:52am UTC](https://www.ruby-forum.com/t/separate-log-for-robot-page-access/183021/2 "2010-02-06T10:52:14Z")
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 ; > } > > ``` > **[GitHub - nginxinc/nginx-wiki: ARCHIVED -- Source for the now archived NGINX Wiki...](https://github.com/nginxinc/nginx-wiki)** > > ARCHIVED -- Source for the now archived NGINX Wiki section of https://www.nginx.com This won’t work, see third example. Maxim D. ---
**Author:** ![Wohbah](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/e36b37/32.png) [@Wohbah](https://www.ruby-forum.com/u/Wohbah)\ **Post date:** [February 6, 2010, 11:33am UTC](https://www.ruby-forum.com/t/separate-log-for-robot-page-access/183021/3 "2010-02-06T11:33:12Z")
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](http://n2.nabble.com/Separate-Log-for-Robot-Page-Access-tp4524448p4524797.html) Sent from the nginx mailing list archive at [Nabble.com](http://Nabble.com). ---
**Author:** ![Wohbah](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/e36b37/32.png) [@Wohbah](https://www.ruby-forum.com/u/Wohbah)\ **Post date:** [February 6, 2010, 10:32pm UTC](https://www.ruby-forum.com/t/separate-log-for-robot-page-access/183021/4 "2010-02-06T22:32:15Z")
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. ---
**Author:** ![Wohbah](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/e36b37/32.png) [@Wohbah](https://www.ruby-forum.com/u/Wohbah)\ **Post date:** [February 7, 2010, 3:21am UTC](https://www.ruby-forum.com/t/separate-log-for-robot-page-access/183021/5 "2010-02-07T03:21:59Z")
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. ---
**Author:** ![Wohbah](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/e36b37/32.png) [@Wohbah](https://www.ruby-forum.com/u/Wohbah)\ **Post date:** [February 7, 2010, 1:45am UTC](https://www.ruby-forum.com/t/separate-log-for-robot-page-access/183021/6 "2010-02-07T01:45:59Z")
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](http://n2.nabble.com/Separate-Log-for-Robot-Page-Access-tp4524448p4527589.html) Sent from the nginx mailing list archive at [Nabble.com](http://Nabble.com). ---
**Author:** ![Wohbah](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/e36b37/32.png) [@Wohbah](https://www.ruby-forum.com/u/Wohbah)\ **Post date:** [February 9, 2010, 11:26pm UTC](https://www.ruby-forum.com/t/separate-log-for-robot-page-access/183021/7 "2010-02-09T23:26:17Z")
On Sat, Feb 6, 2010 at 2:32 AM, Wohbah [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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](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. Excuse the vernacular but it fits perfectly… NginX rarely takes a shit for me, mate! Thanks, – Merlin