access log control while maintaining internal redirection to WordPress

[Jan-Philip Gehrcke]

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

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
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>