nginx sent_http header variable not truthy
I would like nginx to change its behavior based on a response header from a backend.
My backend (also nginx) returns a Foo header:
HTTP/1.1 200 OK
Server: nginx/1.15.5
Foo: true
If the Foo header is set, I would like to change the behavior.
If I use the following config, $sent_http_foo doesn't appear to be truthy and the header isn't set.
if ($sent_http_foo) {
add_header "Foo-Header-Set" "true";
}
However, if I use this config instead:
add_header "Foo-Header-Value" "$sent_http_foo";
I see the new header with true in my response.
Is it possible to use the $sent_http_* variables in this way?
http nginx
asked Nov 12 '18 at 15:40
Charlie EganCharlie Egan
1,75542239
add a comment |
I would like nginx to change its behavior based on a response header from a backend.
My backend (also nginx) returns a Foo header:
HTTP/1.1 200 OK
Server: nginx/1.15.5
Foo: true
If the Foo header is set, I would like to change the behavior.
If I use the following config, $sent_http_foo doesn't appear to be truthy and the header isn't set.
if ($sent_http_foo) {
add_header "Foo-Header-Set" "true";
}
However, if I use this config instead:
add_header "Foo-Header-Value" "$sent_http_foo";
I see the new header with true in my response.
Is it possible to use the $sent_http_* variables in this way?
http nginx
asked Nov 12 '18 at 15:40
Charlie EganCharlie Egan
1,75542239
add a comment |
I would like nginx to change its behavior based on a response header from a backend.
My backend (also nginx) returns a Foo header:
HTTP/1.1 200 OK
Server: nginx/1.15.5
Foo: true
If the Foo header is set, I would like to change the behavior.
If I use the following config, $sent_http_foo doesn't appear to be truthy and the header isn't set.
if ($sent_http_foo) {
add_header "Foo-Header-Set" "true";
}
However, if I use this config instead:
add_header "Foo-Header-Value" "$sent_http_foo";
I see the new header with true in my response.
Is it possible to use the $sent_http_* variables in this way?
http nginx
asked Nov 12 '18 at 15:40
Charlie EganCharlie Egan
1,75542239
I would like nginx to change its behavior based on a response header from a backend.
My backend (also nginx) returns a Foo header:
HTTP/1.1 200 OK
Server: nginx/1.15.5
Foo: true
If the Foo header is set, I would like to change the behavior.
If I use the following config, $sent_http_foo doesn't appear to be truthy and the header isn't set.
if ($sent_http_foo) {
add_header "Foo-Header-Set" "true";
}
However, if I use this config instead:
add_header "Foo-Header-Value" "$sent_http_foo";
I see the new header with true in my response.
Is it possible to use the $sent_http_* variables in this way?
http nginx
http nginx
asked Nov 12 '18 at 15:40
Charlie EganCharlie Egan
1,75542239
asked Nov 12 '18 at 15:40
Charlie EganCharlie Egan
1,75542239
asked Nov 12 '18 at 15:40
Charlie EganCharlie Egan
1,75542239
asked Nov 12 '18 at 15:40
Charlie EganCharlie Egan
1,75542239
asked Nov 12 '18 at 15:40
Charlie EganCharlie Egan
1,75542239
1,75542239
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
This is quite an old mailing list but it is related to your question - Nginx mailing
In the mailing list you can read -
Both "set" and "if" directives you mentioned are executed before
a request is sent to upstream.
and at this point there is no foo header in the response....
"if" or "set" directives isn't going to work, and this is what
causes behavior you see.
Moreover, you can read further about If Is Evil
Directive if has problems when used in location context, in some cases it doesn’t do what you expect but something completely different instead. In some cases it even segfaults. It’s generally a good idea to avoid it if possible.
In conclusion - the way you do is totally fine:
add_header "Foo-Header-Value" "$sent_http_foo";
answered Nov 15 '18 at 14:29
Gal SGal S
757213
So I guess what I'm trying to do here might not actually be possible with plain NGINX. Perhaps a slightly odd requirement, but I was trying to block requests when the backend returns a certain header (block as in return a 4XX).
– Charlie Egan
Nov 16 '18 at 10:18
@CharlieEgan why don't you just have the backend return 4xx directly?
– cnst
Nov 17 '18 at 21:36
1
@CharlieEgan - AFAIK you don't have this in the plain NGINX. You can create your module that uses headers_out that checks the content of this header and return 4XX. This can help you NGINX Tutorial: Developing Modules but I think you need a good reason to go to that direction.
– Gal S
Nov 18 '18 at 8:29
@cnst this is as a generic solution for a number of legacy backends that I don't have control over.
– Charlie Egan
Nov 18 '18 at 10:17
@GalS thanks for the extra info & answer above. Much appreciated.
– Charlie Egan
Nov 18 '18 at 10:18
|
show 1 more comment
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53265474%2fnginx-sent-http-header-variable-not-truthy%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
This is quite an old mailing list but it is related to your question - Nginx mailing
In the mailing list you can read -
Both "set" and "if" directives you mentioned are executed before
a request is sent to upstream.
and at this point there is no foo header in the response....
"if" or "set" directives isn't going to work, and this is what
causes behavior you see.
Moreover, you can read further about If Is Evil
Directive if has problems when used in location context, in some cases it doesn’t do what you expect but something completely different instead. In some cases it even segfaults. It’s generally a good idea to avoid it if possible.
In conclusion - the way you do is totally fine:
add_header "Foo-Header-Value" "$sent_http_foo";
answered Nov 15 '18 at 14:29
Gal SGal S
757213
So I guess what I'm trying to do here might not actually be possible with plain NGINX. Perhaps a slightly odd requirement, but I was trying to block requests when the backend returns a certain header (block as in return a 4XX).
– Charlie Egan
Nov 16 '18 at 10:18
@CharlieEgan why don't you just have the backend return 4xx directly?
– cnst
Nov 17 '18 at 21:36
1
@CharlieEgan - AFAIK you don't have this in the plain NGINX. You can create your module that uses headers_out that checks the content of this header and return 4XX. This can help you NGINX Tutorial: Developing Modules but I think you need a good reason to go to that direction.
– Gal S
Nov 18 '18 at 8:29
@cnst this is as a generic solution for a number of legacy backends that I don't have control over.
– Charlie Egan
Nov 18 '18 at 10:17
@GalS thanks for the extra info & answer above. Much appreciated.
– Charlie Egan
Nov 18 '18 at 10:18
|
show 1 more comment
This is quite an old mailing list but it is related to your question - Nginx mailing
In the mailing list you can read -
Both "set" and "if" directives you mentioned are executed before
a request is sent to upstream.
and at this point there is no foo header in the response....
"if" or "set" directives isn't going to work, and this is what
causes behavior you see.
Moreover, you can read further about If Is Evil
Directive if has problems when used in location context, in some cases it doesn’t do what you expect but something completely different instead. In some cases it even segfaults. It’s generally a good idea to avoid it if possible.
In conclusion - the way you do is totally fine:
add_header "Foo-Header-Value" "$sent_http_foo";
answered Nov 15 '18 at 14:29
Gal SGal S
757213
So I guess what I'm trying to do here might not actually be possible with plain NGINX. Perhaps a slightly odd requirement, but I was trying to block requests when the backend returns a certain header (block as in return a 4XX).
– Charlie Egan
Nov 16 '18 at 10:18
@CharlieEgan why don't you just have the backend return 4xx directly?
– cnst
Nov 17 '18 at 21:36
1
@CharlieEgan - AFAIK you don't have this in the plain NGINX. You can create your module that uses headers_out that checks the content of this header and return 4XX. This can help you NGINX Tutorial: Developing Modules but I think you need a good reason to go to that direction.
– Gal S
Nov 18 '18 at 8:29
@cnst this is as a generic solution for a number of legacy backends that I don't have control over.
– Charlie Egan
Nov 18 '18 at 10:17
@GalS thanks for the extra info & answer above. Much appreciated.
– Charlie Egan
Nov 18 '18 at 10:18
|
show 1 more comment
This is quite an old mailing list but it is related to your question - Nginx mailing
In the mailing list you can read -
Both "set" and "if" directives you mentioned are executed before
a request is sent to upstream.
and at this point there is no foo header in the response....
"if" or "set" directives isn't going to work, and this is what
causes behavior you see.
Moreover, you can read further about If Is Evil
Directive if has problems when used in location context, in some cases it doesn’t do what you expect but something completely different instead. In some cases it even segfaults. It’s generally a good idea to avoid it if possible.
In conclusion - the way you do is totally fine:
add_header "Foo-Header-Value" "$sent_http_foo";
answered Nov 15 '18 at 14:29
Gal SGal S
757213
This is quite an old mailing list but it is related to your question - Nginx mailing
In the mailing list you can read -
Both "set" and "if" directives you mentioned are executed before
a request is sent to upstream.
and at this point there is no foo header in the response....
"if" or "set" directives isn't going to work, and this is what
causes behavior you see.
Moreover, you can read further about If Is Evil
Directive if has problems when used in location context, in some cases it doesn’t do what you expect but something completely different instead. In some cases it even segfaults. It’s generally a good idea to avoid it if possible.
In conclusion - the way you do is totally fine:
add_header "Foo-Header-Value" "$sent_http_foo";
answered Nov 15 '18 at 14:29
Gal SGal S
757213
edited Nov 15 '18 at 15:27
answered Nov 15 '18 at 14:29
Gal SGal S
757213
answered Nov 15 '18 at 14:29
Gal SGal S
757213
answered Nov 15 '18 at 14:29
Gal SGal S
757213
757213
So I guess what I'm trying to do here might not actually be possible with plain NGINX. Perhaps a slightly odd requirement, but I was trying to block requests when the backend returns a certain header (block as in return a 4XX).
– Charlie Egan
Nov 16 '18 at 10:18
@CharlieEgan why don't you just have the backend return 4xx directly?
– cnst
Nov 17 '18 at 21:36
1
@CharlieEgan - AFAIK you don't have this in the plain NGINX. You can create your module that uses headers_out that checks the content of this header and return 4XX. This can help you NGINX Tutorial: Developing Modules but I think you need a good reason to go to that direction.
– Gal S
Nov 18 '18 at 8:29
@cnst this is as a generic solution for a number of legacy backends that I don't have control over.
– Charlie Egan
Nov 18 '18 at 10:17
@GalS thanks for the extra info & answer above. Much appreciated.
– Charlie Egan
Nov 18 '18 at 10:18
|
show 1 more comment
So I guess what I'm trying to do here might not actually be possible with plain NGINX. Perhaps a slightly odd requirement, but I was trying to block requests when the backend returns a certain header (block as in return a 4XX).
– Charlie Egan
Nov 16 '18 at 10:18
@CharlieEgan why don't you just have the backend return 4xx directly?
– cnst
Nov 17 '18 at 21:36
1
@CharlieEgan - AFAIK you don't have this in the plain NGINX. You can create your module that uses headers_out that checks the content of this header and return 4XX. This can help you NGINX Tutorial: Developing Modules but I think you need a good reason to go to that direction.
– Gal S
Nov 18 '18 at 8:29
@cnst this is as a generic solution for a number of legacy backends that I don't have control over.
– Charlie Egan
Nov 18 '18 at 10:17
@GalS thanks for the extra info & answer above. Much appreciated.
– Charlie Egan
Nov 18 '18 at 10:18
So I guess what I'm trying to do here might not actually be possible with plain NGINX. Perhaps a slightly odd requirement, but I was trying to block requests when the backend returns a certain header (block as in return a 4XX).
– Charlie Egan
Nov 16 '18 at 10:18
So I guess what I'm trying to do here might not actually be possible with plain NGINX. Perhaps a slightly odd requirement, but I was trying to block requests when the backend returns a certain header (block as in return a 4XX).
– Charlie Egan
Nov 16 '18 at 10:18
@CharlieEgan why don't you just have the backend return 4xx directly?
– cnst
Nov 17 '18 at 21:36
@CharlieEgan why don't you just have the backend return 4xx directly?
– cnst
Nov 17 '18 at 21:36
1
1
@CharlieEgan - AFAIK you don't have this in the plain NGINX. You can create your module that uses headers_out that checks the content of this header and return 4XX. This can help you NGINX Tutorial: Developing Modules but I think you need a good reason to go to that direction.
– Gal S
Nov 18 '18 at 8:29
@CharlieEgan - AFAIK you don't have this in the plain NGINX. You can create your module that uses headers_out that checks the content of this header and return 4XX. This can help you NGINX Tutorial: Developing Modules but I think you need a good reason to go to that direction.
– Gal S
Nov 18 '18 at 8:29
@cnst this is as a generic solution for a number of legacy backends that I don't have control over.
– Charlie Egan
Nov 18 '18 at 10:17
@cnst this is as a generic solution for a number of legacy backends that I don't have control over.
– Charlie Egan
Nov 18 '18 at 10:17
@GalS thanks for the extra info & answer above. Much appreciated.
– Charlie Egan
Nov 18 '18 at 10:18
@GalS thanks for the extra info & answer above. Much appreciated.
– Charlie Egan
Nov 18 '18 at 10:18
|
show 1 more comment
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53265474%2fnginx-sent-http-header-variable-not-truthy%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
