Map $uri in 1.3.0+ NOT working in 1.6.0+

We have the following code that worked in 1.3.16…

Map VWS URI’s to HTTP ($use_secure=0), HTTPS ($use_secure=1) or keep

same
($use_secure=2)
map $uri $use_secure {
default 0;
~^/sites/ 2;
~^/account/ 1;
}

And this file for the main config that includes the map file:

include /srv/etc/web_x/nginx/include/example.org_prepend.conf;

server {
listen 192.168.0.101:80;
server_name p3.example.com;

If map says that this resource should be served over HTTPS (vs. HTTP)

then
redirect now
if ($use_secure = 1) {
return 301 https://securep3.example.com$request_uri;
}
}

However in 1.6.0 and 1.6.1 $use_secure is ALWAYS 0 no matter what URI is
used.

I have even tried using $request_uri instead of $uri and it still won’t
work.

Why is this not backward compatible OR what am I doing wrong?

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,253733,253733#msg-253733

Turns out that this was a mis-configuration on our end and that it works
great in 1.6.0+

We had the issue on a test server that had 2 sites sharing the same IP
address but moreover both sites assigned the $use_secure variable so it
was
being overwritten by the 2nd site and always set to 0 b/c of no match of
a
URI with the 1st site against the 2nd site. Resolution was simple… I
just
suffixed the variables appropriately for each site… e.g.
$use_secure_xx
and $use_secure_yy and the problem went away.

Wasted a lot of time trying to debug. Perhaps Nginx “can” be smarter
and
catch such a situation (i.e. that 2 or more map directives set the same
variable) and perhaps issue a warning. Either way though no big deal…
it
just was hard to pin down… as it involved multiple file domain
configs.

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,253733,253735#msg-253735

On Thursday 02 October 2014 23:08:53 nikolaos2012 wrote:

We have the following code that worked in 1.3.16…

Map VWS URI’s to HTTP ($use_secure=0), HTTPS ($use_secure=1) or keep same

($use_secure=2)
map $uri $use_secure {
default 0;
~^/sites/ 2;
~^/account/ 1;
}
[…]

$uri in the “map” directive usually means that you’re doing it wrong.

For mapping configuration on URIs there’s special and highly optimized
directive, called “location”.

The only reason to use map instead of location could be to save some
memory when you have thousands of URIs to map.

wbr, Valentin V. Bartenev

Hi Valentin,

I have read that I should be using the location directive unless I have
numerous mappings in other places.

In this case we have about a dozen mappings.

But I am curious if I used the location directive what would the above
mapping example translate to so that it results in a $use_secure
variable
that we can include in another file so that it can be used inside
multiple
server blocks.

Why do we do it this way… b/c we have standardized templates for the
core
server blocks and mappings specific to the domain are prepended to the
main
file.

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,253733,253749#msg-253749

On Friday 03 October 2014 12:43:29 nikolaos2012 wrote:

server blocks.
[…]

If I understand you case right, then it can be something like that:

location /sites/ {
return 301 https://secure$host$request_uri;
}

location /account/ {
return 301 https://secure$host$request_uri;
}

wbr, Valentin V. Bartenev

Hi Valentin,

I am not sure that what you provided is exactly what I am trying to
achieve.

What I want is if someone hits port 80 (HTTP) with /account that they
redirect to /account on port 443 (HTTPS). However, if they come in on
port
443 (HTTPS) with /account that they remain on port 443 (HTTPS). Similar
rules exist for keeping certain URI’s on HTTP or allowing certain URIs
to
use HTTP/HTTPS (basically we don’t care).

With the example you provided I would need to embed these location
directives into the respective Server sections of our main template file
(unless I am missing something) and thus would introduce domain /
application specific behaviour into the template VS. how we are doing it
now
in that application specific behaviour is limited to pre-pended or
post-pended include files so as to create clean separation across
multiple
domains.

While the map directive may not be the most efficient it has the
benefits of
being the most compact, easiest to maintain and that it can be decoupled
from our core common Nginx template files i.e. it can live outside the
Server directive. So at this point its a tradeoff between simplicity
and
speed.

Just how bad will the map (say about a dozen mappings) perform in
comparison
to location directives?

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,253733,253764#msg-253764