Welcome! Log In Create A New Profile

Advanced

Re: access log control while maintaining internal redirection to WordPress

Jan-Philip Gehrcke
September 25, 2012 04:16AM
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@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Subject Author Posted

access log control while maintaining internal redirection to WordPress

Jan-Philip Gehrcke September 24, 2012 05:12PM

Re: access log control while maintaining internal redirection to WordPress

Maxim Dounin September 24, 2012 05:22PM

Re: access log control while maintaining internal redirection to WordPress

Jan-Philip Gehrcke September 25, 2012 04:16AM

Re: access log control while maintaining internal redirection to WordPress

Igor Sysoev September 25, 2012 04:38AM

Re: access log control while maintaining internal redirection to WordPress

Jan-Philip Gehrcke September 25, 2012 03:14PM

Re: access log control while maintaining internal redirection to WordPress

Igor Sysoev September 25, 2012 03:18PM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 238
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready