# Generating redirects to internal named locations

**URL:** <https://www.ruby-forum.com/t/generating-redirects-to-internal-named-locations/210415>\
**Category:** NGINX\
**Created:** [August 7, 2011, 11:18pm UTC](https://www.ruby-forum.com/t/generating-redirects-to-internal-named-locations/210415 "2011-08-07T23:18:53Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![dubstep](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/cdc98d/32.png) [@dubstep](https://www.ruby-forum.com/u/dubstep)\
**Post date:** [August 7, 2011, 11:18pm UTC](https://www.ruby-forum.com/t/generating-redirects-to-internal-named-locations/210415/1 "2011-08-07T23:18:53Z")

</div>

Greetings nginx gurus. 🙂 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 - removed\_email\_address@domain.invalid

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

---

<div class="post-metadata">

**Author:** ![daveh](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/85e7bf/32.png) [@daveh](https://www.ruby-forum.com/u/daveh)\
**Post date:** [August 8, 2011, 12:08am UTC](https://www.ruby-forum.com/t/generating-redirects-to-internal-named-locations/210415/2 "2011-08-08T00:08:19Z")

</div>

On 8/8/11, Dave H. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> Greetings nginx gurus. 🙂 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.

---

<div class="post-metadata">

**Author:** ![daveh](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/85e7bf/32.png) [@daveh](https://www.ruby-forum.com/u/daveh)\
**Post date:** [August 8, 2011, 6:35pm UTC](https://www.ruby-forum.com/t/generating-redirects-to-internal-named-locations/210415/3 "2011-08-08T18:35:10Z")

</div>

On 8/8/11, Dave H. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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? 🙂

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

---

<div class="post-metadata">

**Author:** ![daveh](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/85e7bf/32.png) [@daveh](https://www.ruby-forum.com/u/daveh)\
**Post date:** [August 8, 2011, 5:58am UTC](https://www.ruby-forum.com/t/generating-redirects-to-internal-named-locations/210415/4 "2011-08-08T05:58:40Z")

</div>

Alexandr G. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) writes:

> On 8/8/11, Dave H. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:
> 
> > Greetings nginx gurus. 🙂 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? 🙂

Dave H. - Consultant - Altadena CA, USA - [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

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

---

<div class="post-metadata">

**Author:** ![daveh](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/85e7bf/32.png) [@daveh](https://www.ruby-forum.com/u/daveh)\
**Post date:** [August 10, 2011, 8:28am UTC](https://www.ruby-forum.com/t/generating-redirects-to-internal-named-locations/210415/5 "2011-08-10T08:28:39Z")

</div>

Alexandr G. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) writes:

> On 8/8/11, Dave H. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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? 🙂  
> > Yes, you got that right 🙂  
> > 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? 🙂

Dave H. - Consultant - Altadena CA, USA - [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

> > > The opinions expressed above are entirely my own \<\<\<

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

---

<div class="post-metadata">

**Author:** ![daveh](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/85e7bf/32.png) [@daveh](https://www.ruby-forum.com/u/daveh)\
**Post date:** [August 10, 2011, 1:14pm UTC](https://www.ruby-forum.com/t/generating-redirects-to-internal-named-locations/210415/6 "2011-08-10T13:14:33Z")

</div>

> 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](http://wiki.nginx.org/NginxHttpMainModule#include)  
/etc/nginx/fastcgi\_params;

Regards

```
 Paul Findlay

```
