Access log control while maintaining internal redirection to WordPress

Server NGINX
1

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?

Thanks!

Jan-Philip

2

Hello!

On Mon, Sep 24, 2012 at 11:11:21PM +0200, Jan-Philip Gehrcke wrote:

try_files $uri $uri/ /index.php?q=$args;

beginning portion of the query - the most specific match will be
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 D.

3

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?

Cheers,

Jan-Philip

4

Thanks for your opinion, Igor. Would it also be safe to use include
statements for blocks that occur multiple times?

Jan-Philip

5

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

6

On Sep 25, 2012, at 23:12 , Jan-Philip Gehrcke wrote:

Thanks for your opinion, Igor. Would it also be safe to use include statements
for blocks that occur multiple times?

Yes, it’ safe. Although I prefer not to use “include” for this purpose,
since it complicates the find-and-replace strategy.

–
Igor S.