Request/response transformation in Nginx - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

What is the output of this NGINX configuration snippet?

Given the following NGINX configuration, what will be the response body when a client requests /hello?

Nginx

location /hello {
    default_type text/plain;
    return 200 'Hello, NGINX!';
}

A The client receives a plain text response with body: Hello, NGINX!

B The client receives a JSON response with body: {"message": "Hello, NGINX!"}

C The client receives an empty response with status 200

D The client receives a 404 Not Found error

💡 Hint

Look at the return directive and the default_type setting.

The return 200 'Hello, NGINX!'; directive sends a 200 status with the given plain text body. The default_type text/plain; ensures the Content-Type header is text/plain.

❓ Configuration

intermediate

Which configuration correctly rewrites the request URI from /old-path to /new-path internally?

You want NGINX to internally rewrite requests from /old-path to /new-path without redirecting the client. Which option achieves this?

A

location /old-path {
    rewrite ^/old-path$ /new-path break;
}

B

location /old-path {
    return 301 /new-path;
}

C

location /old-path {
    proxy_pass http://backend/new-path;
}

D

location /old-path {
    rewrite ^/old-path$ /new-path redirect;
}

💡 Hint

Consider the difference between internal rewrite and client redirect.

The rewrite ... break; directive rewrites the URI internally without telling the client. The return 301 and rewrite ... redirect; cause client redirects. proxy_pass forwards requests to a backend, not a rewrite.

❓ Troubleshoot

advanced

Why does this NGINX config not modify the response body as expected?

You want to replace all occurrences of 'foo' with 'bar' in the response body using this config:

location / {
    sub_filter 'foo' 'bar';
    sub_filter_once off;
    proxy_pass http://backend;
}

But the response body remains unchanged. What is the most likely cause?

A The <code>proxy_pass</code> URL is incorrect and backend is unreachable

B The <code>sub_filter</code> module only works with <code>proxy_set_header</code> directives

C The response Content-Type header is not one of the types <code>sub_filter</code> modifies by default

D The <code>sub_filter_once off;</code> directive disables all substitutions

💡 Hint

Check the Content-Type header of the response from backend.

The sub_filter module only modifies response bodies with Content-Type headers matching text/html or similar by default. If the backend sends application/json or others, sub_filter won't change the body unless configured.

🔀 Workflow

advanced

What is the correct order of directives to transform a request URI and modify response headers in NGINX?

Arrange these steps in the correct order to transform a request URI from /api/v1 to /v1/api and add a custom response header X-Custom: true:

A 4,3,1,2

B 4,2,1,3

C 1,4,3,2

D 4,1,3,2

💡 Hint

Think about how NGINX processes requests and responses in order.

First, define the location block (4). Then rewrite the URI internally (1). Next, proxy the request to backend (3). Finally, add the custom response header (2) which modifies the response before sending to client.

✅ Best Practice

expert

Which approach is best to safely transform JSON response bodies in NGINX without breaking the JSON structure?

You want to replace a specific field value in JSON responses from your backend. Which method is safest and most reliable?

A Use <code>sub_filter</code> to replace the field value as plain text in the response body

B Use a Lua script with <code>ngx_http_lua_module</code> to parse and modify JSON before sending

C Use <code>proxy_set_header</code> to modify the JSON response headers

D Use <code>rewrite</code> directive to change the JSON response body

💡 Hint

Consider JSON structure and how text replacement might affect it.

Using sub_filter risks breaking JSON if replacements are partial or affect syntax. proxy_set_header only changes headers, not body. rewrite changes request URIs, not response bodies. Lua scripting allows safe parsing and modification of JSON content.