0

Please help me to understand why the following proxy configuration does not set the header X-Discourse-Echo-Proxy:

server {
  listen 80;
  server_name corsproxy.discourseecho.com;

  error_log /data/nginx/proxy-debug warn;
  # access_log /data/nginx/proxy-access;

  location / {

    proxy_redirect off;
    proxy_set_header Host $arg_proxy_target_domain;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    proxy_cache discourse_corsproxy;
    proxy_cache_valid any 30m;
    proxy_cache_lock on;
    proxy_cache_lock_age 7s;
    proxy_cache_lock_timeout 5s;
    proxy_cache_methods GET HEAD POST;

    proxy_ignore_headers Cache-Control X-Accel-Expires Expires Set-Cookie Vary;
    proxy_hide_header Set-Cookie;
    proxy_hide_header Cache-Control;
    proxy_hide_header Expires;
    proxy_hide_header X-Accel-Expires;
    proxy_hide_header Vary;
    proxy_hide_header Access-Control-Allow-Origin;
    proxy_hide_header Access-Control-Allow-Credentials;

    add_header X-Cache-Status $upstream_cache_status always;
    add_header X-Discourse-Echo-Proxy "1" always;

    # Nginx doesn't support nested If statements, so we
    # concatenate compound conditions on the $cors variable
    # and process later
   # If request comes from allowed subdomain
    # (discourseecho.com) then we enable CORS
    if ($http_origin ~* (https?://discourseecho\.com$)) {
       set $cors "1";
    }

    # If request comes from my home IP (Adelaide), enable CORS
    if ($remote_addr = "103.192.193.144") {
      set $cors "1";
    }

    # OPTIONS indicates a CORS pre-flight request
    if ($request_method = 'OPTIONS') {
       set $cors "${cors}o";
    }

    # Append CORS headers to any request from
    # allowed CORS domain, except OPTIONS
    if ($cors = "1") {
       add_header Access-Control-Allow-Origin $http_origin always;
       add_header Access-Control-Allow-Credentials "true" always;
       proxy_pass $arg_proxy_target_protocol://$arg_proxy_target_domain;
    }
   # OPTIONS (pre-flight) request from allowed
    # CORS domain. return response directly
    if ($cors = "1o") {
       add_header Access-Control-Allow-Origin $http_origin' always;
       add_header Access-Control-Allow-Methods "GET, POST, OPTIONS, PUT, DELETE" always;
       add_header Access-Control-Allow-Credentials "true" always;
       add_header Access-Control-Allow-Headers "Origin,Content-Type,Accept" always;
       add_header Content-Length 0;
       add_header Content-Type text/plain;
       return 204;
    }

    # Requests from non-allowed CORS domains
    proxy_pass $arg_proxy_target_protocol://$arg_proxy_target_domain;
  }
}

I expect the header to be added because of the following instruction:

add_header X-Discourse-Echo-Proxy "1" always;

But whatever HTTP requests I make, no such a header is present in responses. No errors or warnings in the log file. What should I check to identify the problem?

4
  • What version of nginx are you using?
    – ALex_hha
    Mar 20, 2016 at 10:12
  • The version is 1.8.1
    – meglio
    Mar 20, 2016 at 10:13
  • I've tried a GET and I can see the header in the response Mar 20, 2016 at 10:48
  • Okay, in my case it fails when calling this url from localhost: http://corsproxy.discourseecho.com/latest.json?proxy_target_domain=experts.feverbee.com&proxy_target_protocol=https (using Postman client). I suspect may be something about the if statements, but can't get my head around it.
    – meglio
    Mar 20, 2016 at 11:06

1 Answer 1

1

I have a feeling that the if statements may defeat add_header directives in the enclosing block. In the documentation it says:- "There could be several add_header directives. These directives are inherited from the previous level if and only if there are no add_header directives defined on the current level." That would mean that you may have to repeat yourself inside the if blocks.

1
  • Careful use of includes will take care of the repetition problem. Sep 6, 2021 at 3:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .