Generating redirects to internal named locations

Server NGINX
1

Greetings nginx gurus. :slight_smile: Is there a better way to generate a redirect
to a named location than this?

location @perl {
fastcgi…
}
…
location ~ .pl$ {
try_files /this_should_never_exist @perl;
}

Thanks in advance for any insight.

Dave H. - Consultant - Altadena CA, USA - [email protected]

The opinions expressed above are entirely my own <<<

A Law of Computer Programming:
Make it possible for programmers to write in English
and you will find the programmers cannot write in English.

2

On 8/8/11, Dave H. [email protected] wrote:

Greetings nginx gurus. :slight_smile: Is there a better way to generate a redirect
to a named location than this?

location ~ .pl$ {
try_files /this_should_never_exist @perl;
}

Another way is to use error_page in conjunction with return.
But in this case you should just replace try_files with your named
location’s config.

3

On 8/8/11, Dave H. [email protected] wrote:

If I have several location blocks in a server block, and I want to use
just one location block that has my fastcgi definitions for perl (hence
@perl), are you recommending I just duplicate all the configuration
in each location block that needs to redirect to perl?

Did I get that right? :slight_smile:

Yes, you got that right :slight_smile:
Avoiding abstractions is a good thing here. Less likely to stumble on
a bug, easier to read later, etc.

4

Alexandr G. [email protected] writes:

On 8/8/11, Dave H. [email protected] wrote:

Greetings nginx gurus. :slight_smile: Is there a better way to generate a redirect
to a named location than this?
location ~ .pl$ {
try_files /this_should_never_exist @perl;
}
Another way is to use error_page in conjunction with return.
But in this case you should just replace try_files with your named
location’s config.

If I have several location blocks in a server block, and I want to use
just one location block that has my fastcgi definitions for perl (hence
@perl), are you recommending I just duplicate all the configuration
in each location block that needs to redirect to perl?

Saying this another way, by example:

location @perl {
# 20 lines of fast cgi defs
}

location /realm_a {
auth_basic “realm_a”;
location ~ .pl$ {
try_files /does_not_exist @perl;
}
}

location /realm_b {
auth_basic “realm_b”;
location ~ .pl$ {
try_files /does_not_exist @perl;
}
}

location /realm_c {
auth_basic “realm_c”;
location ~ .pl$ {
try_files /does_not_exist @perl;
}
}

Your recommendation is to do this:

location /realm_a {
auth_basic “realm_a”;
location ~ .pl$ {
# 20 lines of fast cgi defs
}
}

location /realm_b {
auth_basic “realm_b”;
location ~ .pl$ {
# 20 lines of fast cgi defs
}
}

location /realm_c {
auth_basic “realm_c”;
location ~ .pl$ {
# 20 lines of fast cgi defs
}
}

Did I get that right? :slight_smile:

Dave H. - Consultant - Altadena CA, USA - [email protected]

The opinions expressed above are entirely my own <<<

A “No” uttered from deepest conviction is better and greater
than a “Yes” merely uttered to please, or what is worse, to
avoid trouble. – Mahatma Ghandi

5

Alexandr G. [email protected] writes:

On 8/8/11, Dave H. [email protected] wrote:

If I have several location blocks in a server block, and I want to use
just one location block that has my fastcgi definitions for perl (hence
@perl), are you recommending I just duplicate all the configuration
in each location block that needs to redirect to perl?
Did I get that right? :slight_smile:
Yes, you got that right :slight_smile:
Avoiding abstractions is a good thing here. Less likely to stumble on
a bug, easier to read later, etc.

Interesting. I would like to learn more about why you think this is a
best practice. Please don’t misread, this is not a criticism. I am quite
curious about any new way of thinking that goes exactly opposite to
established ideas.

In this case, many software developers will tell you that factoring out
common lines of configuration as I have suggested prevents bugs and is
easier to read.

In my example above, if I misconfigure the perl section, I only have to
fix it in one place. If I do it the way you suggest, pasting that
configuration into 20 different location blocks, I have to fix any
configuration bug in 20 places. If I change one location slightly,
it may be hard to spot that there’s a bug in that location.

Maybe I am misunderstanding your rationale? :slight_smile:

Dave H. - Consultant - Altadena CA, USA - [email protected]

The opinions expressed above are entirely my own <<<

“Every extreme attitude is a flight from the self.”
– Eric Hoffer

6

In this case, many software developers will tell you that factoring out
common lines of configuration as I have suggested prevents bugs and is
easier to read.

In my example above, if I misconfigure the perl section, I only have to
fix it in one place. If I do it the way you suggest, pasting that
configuration into 20 different location blocks, I have to fix any
configuration bug in 20 places. If I change one location slightly,
it may be hard to spot that there’s a bug in that location.
You can share much of the fastcgi configuration for each location by
‘factoring’ it out into a separate fastcgi configuration file and
including it like so:

include http://wiki.nginx.org/NginxHttpMainModule#include
/etc/nginx/fastcgi_params;

Regards

 Paul Findlay