Bird
Raised Fist0
Nginxdevops~3 mins

Why Map directive for variable mapping in Nginx? - Purpose & Use Cases

Choose your learning style10 modes available
The Big Idea

Discover how a simple table can replace messy if-else chaos in your nginx setup!

The Scenario

Imagine you have a website that needs to serve different content based on user location or device type. Without a smart way to handle this, you manually write many if-else rules in your server configuration.

The Problem

Manually writing many if-else conditions is slow and error-prone. It makes your configuration messy and hard to maintain. One small mistake can break your site or cause unexpected behavior.

The Solution

The map directive in nginx lets you define a clean, simple table that maps input values to output variables. This keeps your configuration neat and easy to update without complex if-else chains.

Before vs After
✗ Before
if ($http_user_agent ~* 'Mobile') { set $device 'mobile'; } else { set $device 'desktop'; }
✓ After
map $http_user_agent $device { ~*Mobile mobile; default desktop; }
What It Enables

With map, you can quickly and safely customize server behavior based on many conditions, making your site smarter and easier to manage.

Real Life Example

For example, you can use map to detect if a visitor is on a mobile device and serve a mobile-friendly version of your site automatically.

Key Takeaways

Manual if-else rules get complicated and risky.

map creates a clean, easy-to-read mapping table.

This makes your nginx config simpler and more reliable.

Practice

(1/5)
1. What is the primary purpose of the map directive in nginx configuration?
easy
A. To create new variables based on existing variables
B. To define server blocks for different domains
C. To set up SSL certificates
D. To configure load balancing between servers

Solution

  1. Step 1: Understand the role of map in nginx

    The map directive is used to create new variables by mapping values from existing variables.
  2. Step 2: Compare with other nginx directives

    Other options like server blocks, SSL, and load balancing serve different purposes unrelated to variable mapping.
  3. Final Answer:

    To create new variables based on existing variables -> Option A
  4. Quick Check:

    map creates variables [OK]
Hint: Map creates variables from existing ones [OK]
Common Mistakes:
  • Confusing map with server block configuration
  • Thinking map sets SSL or load balancing
  • Assuming map modifies request headers directly
2. Which of the following is the correct syntax to start a map block in nginx?
easy
A. map ($variable, $new_variable) {
B. map $new_variable $variable {
C. map { $variable $new_variable }
D. map $variable $new_variable {

Solution

  1. Step 1: Recall the syntax of the map directive

    The correct syntax is map $variable $new_variable { where the first variable is the source and the second is the target.
  2. Step 2: Eliminate incorrect syntax

    The incorrect options use wrong order or invalid punctuation for nginx configuration.
  3. Final Answer:

    map $variable $new_variable { -> Option D
  4. Quick Check:

    map syntax = map $source $target { [OK]
Hint: Map syntax: map $source $target { [OK]
Common Mistakes:
  • Swapping source and target variables
  • Using parentheses or braces incorrectly
  • Missing the $ sign before variables
3. Given this nginx map configuration:
map $http_user_agent $is_mobile {
    default 0;
    ~*Mobile 1;
}

What will be the value of $is_mobile if the user agent is Mozilla/5.0 (Linux; Mobile)?
medium
A. Mobile
B. 0
C. 1
D. default

Solution

  1. Step 1: Understand the map pattern matching

    The map uses a case-insensitive regex ~*Mobile to match user agents containing 'Mobile'.
  2. Step 2: Check the user agent string

    The user agent contains 'Mobile', so the regex matches and sets $is_mobile to 1.
  3. Final Answer:

    1 -> Option C
  4. Quick Check:

    Regex match 'Mobile' sets value to 1 [OK]
Hint: Regex ~*Mobile matches user agent containing 'Mobile' [OK]
Common Mistakes:
  • Ignoring case-insensitive regex (~*)
  • Assuming default value applies despite match
  • Confusing variable names
4. Identify the error in this nginx map configuration:
map $request_method $allow_method {
    GET yes;
    POST yes;
    DELETE no
}
medium
A. Missing semicolon after DELETE no
B. Incorrect variable names
C. map directive cannot map request methods
D. Using yes/no instead of 1/0 is invalid

Solution

  1. Step 1: Check syntax for each mapping line

    Each line inside map must end with a semicolon. The line DELETE no is missing a semicolon.
  2. Step 2: Validate other options

    Variable names are valid, mapping request methods is allowed, and yes/no strings are acceptable values.
  3. Final Answer:

    Missing semicolon after DELETE no -> Option A
  4. Quick Check:

    Each map line ends with ; [OK]
Hint: Every map entry line ends with a semicolon [OK]
Common Mistakes:
  • Omitting semicolons at line ends
  • Thinking yes/no are invalid values
  • Assuming map can't use request methods
5. You want to create a variable $cache_key that is mobile if the user agent contains 'Mobile', otherwise desktop. Which map configuration correctly achieves this?
hard
A. map $cache_key $http_user_agent { mobile ~*Mobile; desktop default; }
B. map $http_user_agent $cache_key { ~*Mobile mobile; default desktop; }
C. map $http_user_agent $cache_key { default desktop ~*Mobile mobile }
D. map $http_user_agent $cache_key { Mobile mobile; default desktop; }

Solution

  1. Step 1: Confirm correct map syntax and order

    The map directive must have source variable first, target variable second, and each line ends with semicolon.
  2. Step 2: Check pattern matching and default

    map $http_user_agent $cache_key { ~*Mobile mobile; default desktop; } uses case-insensitive regex ~*Mobile to match user agents containing 'Mobile' and sets mobile, else desktop.
  3. Step 3: Eliminate incorrect options

    map $cache_key $http_user_agent { mobile ~*Mobile; desktop default; } reverses variables, one misses semicolons, another uses exact 'Mobile' without regex and may miss case-insensitive matches.
  4. Final Answer:

    map $http_user_agent $cache_key { ~*Mobile mobile; default desktop; } -> Option B
  5. Quick Check:

    Correct map syntax with regex and default [OK]
Hint: Use map $source $target with regex and default [OK]
Common Mistakes:
  • Swapping source and target variables
  • Missing semicolons after lines
  • Not using case-insensitive regex for matching
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard