Proxy_set_header inheritance not working?

Hi,

To prevent duplication between ssl and non-ssl configs
I wanted to do this:

server {
listen 80;
include common.conf;
}

server {
listen 443;
ssl on;
proxy_set_header X_FORWARDED_PROTO https;
include common.conf;
}

where common.conf has a “location /” block that has
its own proxy_set_header directives.

I’m finding that in 0.5.35 the X_FORWARDED_PROTO won’t be
set using this arrangement.

The English proxy_set_header docs state

“This directive is inherited from the previous level when at this
level are not described their directives proxy_set_header.”

http://wiki.codemongers.com/NginxHttpProxyModule#proxy_set_header

Is this saying in a lost-in-translation way that inheritance
only happens when there are no proxy_set_header directives at
the lower level? This may be the case, because I’ve managed to
get this common include arrangement working when the proxy_set_header
directives in the include file are moved from “location /” to
the top level of the file (which is at the server level).

Hello!

On Fri, Mar 28, 2008 at 05:57:18PM +1100, Mark Reginald J. wrote:

[…]

get this common include arrangement working when the proxy_set_header
directives in the include file are moved from “location /” to
the top level of the file (which is at the server level).

Yes. Feel free to fix wording if you may suggest better one.

http://permalink.gmane.org/gmane.comp.web.nginx.english/4022

Maxim D.

Maxim D. wrote:

http://permalink.gmane.org/gmane.comp.web.nginx.english/4022

Thanks Maxim. Sorry I missed the earlier post.

I’ve edited the English proxy_set_header docs, though there’s still
some ambiguity because I don’t know whether the inheritance is from
every higher level or just from the next highest one that has a
proxy_set_header directive.

One other thing: I couldn’t find any English docs about quoting of
directive parameters, Looking at the source, it appears that all
parameters can be wrapped with both single and double-quotes,
though I’m not sure how this interacts with variable expansion.
If you can give me an answer, I’ll write it up on the Wiki, probably
on http://wiki.codemongers.com/NginxConfigNotation

Hello!

On Fri, Apr 11, 2008 at 02:05:18AM +1000, Mark J. wrote:

One other thing: I couldn’t find any English docs about quoting of
directive parameters, Looking at the source, it appears that all
parameters can be wrapped with both single and double-quotes,
though I’m not sure how this interacts with variable expansion.

Quoting has nothing to do with variable expansion. Variable
expansion happens unconditionally if it’s supported for particular
parameter. This is usually documented on per-directive basis.

Please note: quoting supported for directive arguments, but not for
complex entities within them. E.g. the following won’t work:

upstream test {
server 127.0.0.1:8080 max_fails=“10”;
}

If you can give me an answer, I’ll write it up on the Wiki, probably
on http://wiki.codemongers.com/NginxConfigNotation

Looks like right place.

Maxim D.

though I’m not sure how this interacts with variable expansion.
If you can give me an answer, I’ll write it up on the Wiki, probably
on http://wiki.codemongers.com/NginxConfigNotation

Hi

I have just posted some questions about where variable expansion is
valid (seems off and on really?). Very interested to read any new docs
on this?

Ed W

Hello!

On Fri, Apr 11, 2008 at 01:48:12PM +0100, Ed W wrote:

easily make it a function of server name).
No.

Maxim D.

Hi

Quoting has nothing to do with variable expansion. Variable expansion
happens unconditionally if it’s supported for particular parameter.
This is usually documented on per-directive basis.

Please note: quoting supported for directive arguments, but not for
complex entities within them. E.g. the following won’t work:

Is it possible to request variable expansion for log file location? (ie
easily make it a function of server name).

Ed W

Maxim D. wrote:

Please note: quoting supported for directive arguments, but not for
complex entities within them. E.g. the following won’t work:

Is it possible to request variable expansion for log file location?
(ie easily make it a function of server name).

No.

…Because…?

Is it a bad idea? Hard to implement? Something else?

Ed W

Maxim D. wrote:

Quoting has nothing to do with variable expansion. Variable expansion
happens unconditionally if it’s supported for particular parameter.
This is usually documented on per-directive basis.

OK, so quotes are really only needed for parameters that
have either white space or their own quotes.

Please note: quoting supported for directive arguments, but not for
complex entities within them. E.g. the following won’t work:

upstream test {
server 127.0.0.1:8080 max_fails=“10”;
}

So would you have to write:

server 127.0.0.1:8080 ‘max_fails=“10”’;

to ensure the double quotes aren’t treated specially?

I came across this myself with P3P headers. e.g.

add_header P3P ‘CP=“ALL CUR”’

On Fri, Apr 11, 2008 at 02:46:51PM +0100, Ed W wrote:

Is it a bad idea? Hard to implement? Something else?

It’s not too hard to implement. It simply takes some time to implement.

1st, workers must have rights to create files in specified path.
2nd, workers should keep open log files for some time, they may use
ngx_open_cached_file() interface for it.

On Sat, Apr 12, 2008 at 12:07:04AM +1000, Mark J. wrote:

Maxim D. wrote:

Quoting has nothing to do with variable expansion. Variable expansion
happens unconditionally if it’s supported for particular parameter.
This is usually documented on per-directive basis.

OK, so quotes are really only needed for parameters that
have either white space or their own quotes.

Yes.

to ensure the double quotes aren’t treated specially?

Yes, except that =“10” is invalid value.

I came across this myself with P3P headers. e.g.

add_header P3P ‘CP=“ALL CUR”’

Yes.

Hi

  1. Expanding this at configuration stage may be a good idea, but this
    isn’t really a problem since with small number of vhosts you may
    easily configure this by hand, and with huge number of vhosts you
    probaly anyway generate configs.

Yes, expanding at configuration time is what I had in mind, not runtime!

Scripting vhost generation is not always that easy. Also for “medium”
number of vhosts it’s a pain. eg I have quite a few vhosts for
different applications, but each application needs largely a different
overall config, but a similar core config and so I really just want to
“include std_vhost.conf” at the top and get all the standard stuff like
gzip config, log location, etc. Because each app is usually different I
don’t try to template the deployment because that just increases my
deployment complexity (one template per vhost - it saves no time)

If expanding at config time were possible it would be very useful… (I
use this a lot in my old apache config)

I also sent a related question yesterday about using config time
variables for the proxy pass:

For my rails app I reverse proxy to mongrel and this works ok:

 if (!-f $request_filename) {
   proxy_pass http://mongrel_cluster;
   break;
 }

But this does not:

set $cluster “mongrel_cluster”
if (!-f $request_filename) {
proxy_pass http://$cluster;
break;
}

The problem seems to be that the later changes the headers in some way
that mongrel chokes on (see my previous email for the error from
mongrel)

This would really reduce my config complexity to be able to template
this up…

Thanks for listening…

Ed W

Hello!

On Fri, Apr 11, 2008 at 02:46:51PM +0100, Ed W wrote:

Is it a bad idea? Hard to implement? Something else?
Sorry, I misread you question. The answer was for question “Is it
currently possible to use variable …”.

Regarding you real question:

It’s possible, but:

  1. Expanding this for each request will require additional cpu and
    may introduce security issues if improperly used. Additionally,
    it’s IMHO too complicated to work.

  2. Expanding this at configuration stage may be a good idea, but
    this isn’t really a problem since with small number of vhosts you
    may easily configure this by hand, and with huge number of vhosts
    you probaly anyway generate configs.

Maxim D.

OK, I hope I got it right:

http://wiki.codemongers.com/NginxConfigNotation

  1. Expanding this at configuration stage may be a good idea, but
    this isn’t really a problem since with small number of vhosts you
    may easily configure this by hand, and with huge number of vhosts
    you probaly anyway generate configs.

this is already a pain in the ass for us though. its about the only
place that we can use variables. we have to set access log in each
hosts file whereas most everything else comes from variables and there
is a single conf location. if a directory location ever needs to
change, we have to replace it everywhere.

when we have the time we plan on patching nginx to do this of course,
that could be a while and i kind of hope someone else beats us to it.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs