How to change ngx.var.server_name?

mconstable · 2014-01-24T11:02:35+00:00

Thanks agentzh. I tested the patch posted on the nginx mailing list and it works well. Pretty awesome. Saved me several hours of work. Thanks a lotOn Friday,...

How to change ngx.var.server_name?

mconstable

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?

agentzh

Hello!

On Thu, Jan 23, 2014 at 7:02 PM, Mark Constable wrote:
> 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?
>

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

mconstable

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

agentzh

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

mconstable

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.

agentzh

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