access log control while maintaining internal redirection to WordPress

[Igor Sysoev]

On Tue, Sep 25, 2012 at 10:14:07AM +0200, Jan-Philip Gehrcke wrote:
> Thanks, Maxim! This was helpful.
> 
> However, I'd like to discuss the concept a bit further. We're talking 
> about changing only one property for a single location while keeping the 
> rest of the configuration constant -- a pretty common task I guess -- 
> shouldn't there be a more elegant solution?

My exprience of administrating sites with a lot of locations says
that it is much better to concentrate complete configuration inside
location instead of spreading it across whole file.

When you need to add new functionality in the spreaded configuration
you have to check it whole to see possible conflicts. There are no
such issues when you add new functionality in configuration with
completely separated locations given only location prefixes and
without regexes.

The common objection is that you have to dupclicate many common
parameters in all these locations. But when you need to change some
common parameter in many locations, say upstream address, then
find-and-replace in your favourite editor is your friend. It takes
far less time to see if a place should be changed or not.


-- 
Igor Sysoev
http://nginx.com/support.html

> On 09/24/2012 11:20 PM, Maxim Dounin wrote:
> > Hello!
> >
> > On Mon, Sep 24, 2012 at 11:11:21PM +0200, Jan-Philip Gehrcke wrote:
> >
> >> Hello!
> >>
> >> I created a WordPress page with permalink
> >> http://domain.tld/health_status for WordPress health monitoring.
> >> It's accessed frequently, so I don't want these requests to appear
> >> in my access log.
> >>
> >> My basic "rewrite rule" for all WordPress pages is:
> >>
> >> location / {
> >>      try_files $uri $uri/ /index.php?q=$args;
> >> }
> >>
> >> Now, on the same level, I tried
> >>
> >> location /health_status {
> >>      access_log off;
> >>      #try_files $uri $uri/ /index.php?q=$args;
> >>      }
> >>
> >>  From the nginx location documentation: "Literal strings match the
> >> beginning portion of the query - the most specific match will be
> >> used"
> >>
> >> /health_status is more specific than /, so this block takes action
> >> when I request http://domain.tld/health_status.
> >>
> >> With the `try_files` line commented out (as above), the request does
> >> not show up in the access log, hurray, but obviously I just get a
> >> 404 error, because nginx does not redirect this request to
> >> WordPress.
> >>
> >> With the `try_files` line being active, an internal redirect to
> >> WordPress' index.php takes place and the /health_status WordPress
> >> page is shown in the browser. However, after the internal redirect
> >> the location /health_status block is not in action anymore and the
> >> request ends up in the access log.
> >>
> >> How to solve this problem cleanly? Do I now have to add another
> >> block matching the actual /index.php?q=healthstatuswhatever request
> >> that takes place after the internal redirect?
> >
> > Correct solution would be actually configure all you want to
> > happen in location /health_status.  I.e. disable access log in it,
> > _and_ properly handle request there as well.
> >
> > If you are using fastcgi, something like this should work:
> >
> >      location = /health_status {
> >          access_log off;
> >          fastcgi_pass 127.0.0.1:9000;
> >          fastcgi_param SCRIPT_FILENAME $document_root/index.php;
> >          ...
> >      }
> >
> > Similar aproach applies to other backend protocols as well.
> >
> > Maxim Dounin