How to change ngx.var.server_name?

1,599 views
Skip to first unread message

Mark Constable

unread,
Jan 23, 2014, 10:02:34 PM1/23/14
to openre...@googlegroups.com
When I set "server_name ~^(?<domain>.+)$" in a http{} block that gets carried through, literally, to ngx.var.server_name. How could I reset ngx.var.server_name so that it shows that value of $domain rather than the literal regex?

Yichun Zhang (agentzh)

unread,
Jan 25, 2014, 12:15:12 PM1/25/14
to openresty-en
Hello!
The builtin variable $server_name is read-only by design. So you can
never change it. Why not just use your $domain variable?

Regards,
-agentzh

Mark Constable

unread,
Jan 27, 2014, 5:31:03 AM1/27/14
to openre...@googlegroups.com
On 01/26/2014 03:15 AM, Yichun Zhang (agentzh) wrote:
> The builtin variable $server_name is read-only by design. So you can
> never change it. Why not just use your $domain variable?

Yes, $domain works inside nginx.conf but I'm trying to use ngx.var.server_name
inside a lua script and this is the result... http://u2.renta.net/vars

The script is https://github.com/markc/lua/blob/master/vars.lua

Yichun Zhang (agentzh)

unread,
Jan 27, 2014, 3:24:56 PM1/27/14
to openresty-en
Hello!

On Mon, Jan 27, 2014 at 2:31 AM, Mark Constable wrote:
>
> Yes, $domain works inside nginx.conf but I'm trying to use
> ngx.var.server_name
> inside a lua script and this is the result... http://u2.renta.net/vars
>

You can also access $domain in your Lua code, in the form
"ngx.var.domain", as the following example demonstrates:

server {
listen 8081;
server_name ~^(?<domain>.+)$;
location = /t {
content_by_lua '
ngx.say("server name: ", ngx.var.server_name)
ngx.say("domain: ", ngx.var.domain)
';
}
}

Accessing localhost:8081/t gives

server name: ~^(?<domain>.+)$
domain: localhost

which is the expected result.

Best regards,
-agentzh

Mark Constable

unread,
Jan 27, 2014, 9:27:56 PM1/27/14
to openre...@googlegroups.com
On 01/28/2014 06:24 AM, Yichun Zhang (agentzh) wrote:
> server_name ~^(?<domain>.+)$;
>
> ngx.var.server_name = ~^(?<domain>.+)$;
> ngx.var.domain = localhost

Right, I am still surprised ngx.var.server_name does not hold the interpolated
value of server_name but I guess it's for performance reasons. Thank you for
the excellent example, appreciated.

If anyone happens to know of any really simple examples I'd appreciate any links.
I know there are some introductory examples around but once past those it's hard
to find various other examples about different aspects of openresty that do not
descend into a level of complexity that I can no longer easily understand. Trying
to understand how a new language works, and also how it interacts inside nginx,
deserves a good book.

Yichun Zhang (agentzh)

unread,
Jan 28, 2014, 2:51:29 PM1/28/14
to openresty-en
Hello!

On Mon, Jan 27, 2014 at 6:27 PM, Mark Constable wrote:
>
> Right, I am still surprised ngx.var.server_name does not hold the
> interpolated
> value of server_name but I guess it's for performance reasons.

IMHO, it is the right way to uniquely and precisely identify the
current virtual server. This is what the $server_name variable is
designed for, to distinguish various virtual servers (or server {}
blocks) defined in nginx.conf.

The user always has the option to obtain the actual captured value by
the regex anyway (as demonstrated by the $domain variable).

> Thank you for
> the excellent example, appreciated.
>

You're welcome :)

> If anyone happens to know of any really simple examples I'd appreciate any
> links.
> I know there are some introductory examples around

Maybe you have already read the stuffs on openresty.org? Especially
the tutorials below?

http://openresty.org/#eBooks

> but once past those it's
> hard
> to find various other examples about different aspects of openresty that do
> not
> descend into a level of complexity that I can no longer easily understand.

Yeah, I understand the barrier. And I'm going to write more articles
on more advanced topics in a (hopefully) very friendly manner.

> Trying
> to understand how a new language works, and also how it interacts inside
> nginx,
> deserves a good book.
>

Agreed. But writing a book is a big project for its own right. And we
can start by writing more articles and tutorials. And at some point,
it should be relatively easy to re-organize all these into a real book
:)

Thanks for the suggestion!

Best regards,
-agentzh
Reply all
Reply to author
Forward
0 new messages