Listen directive

Hi.

I’ve noticed that in configuratuion like

http {
server {
server_name some.domain.tld;
listen 1.1.1.1;
}
server {
server_name another.domain.tld;
listen 1.1.1.1;
}
server {
server_name one_more.domain.tld *.domain.tld;
listen 1.1.1.1;
}
server {
server_name last.domain.tld;
listen 80;
}
}

weird thing happens: this somehow is similar to the apache directives,
where
you should use exactly the same “address:port” in “VirtualHost” clause
as
you used in “NameVirtualHost address:port” directive. For example if
you
used *, you should use it everywhere, otherwise namevhost won’t work. I
found that at least on 1.2.1 similar thing happens: vhost
“last.domain.tld”
may not get any requests at all, they will be served by the
*.domain.tld,
and, if removed, by the default vhost. So I changed everything to the
“listen 80” and it resolved the situation.

Is it some bug I stepped on, or is this normal, or, may be I just see
things
that aren’t there ?

Thanks.

Posted at Nginx Forum:

On Jul 25, 2013, at 11:23 , drook wrote:

   server_name another.domain.tld;

}
Is it some bug I stepped on, or is this normal, or, may be I just see things
that aren’t there ?

http://nginx.org/en/docs/http/request_processing.html#mixed_name_ip_based_servers


Igor S.

Thanks, I have read this carefully, but this hasn’t become more clear
for me

  • all the examples contain the IP defined, what about undefined IP
    (which,
    as I understand, means “listen to this port everywhere”) ? Does it
    receive
    less priority ? Plus, in my case server_name is defined too. I’m not
    complaining, I’m trying to understand better.

Posted at Nginx Forum:

Thanks a lot, this is much clearer. Actually, ‘absent “listen”, or
“listen”
without both a port and address, assume
the default values for the missing parts’ explains everything, and I
think
the manual would be more clear mentioning this explicitly (still imo).

Posted at Nginx Forum:

On Thu, Jul 25, 2013 at 03:50:02AM -0400, drook wrote:

Hi there,

Thanks, I have read this carefully, but this hasn’t become more clear for me

  • all the examples contain the IP defined, what about undefined IP (which,
    as I understand, means “listen to this port everywhere”) ? Does it receive
    less priority ? Plus, in my case server_name is defined too. I’m not
    complaining, I’m trying to understand better.

A request comes in on an ip:port.

The “listen” directives in each server{} block are considered, to find
the best-match one for that ip:port. Only server{} blocks with that
“listen” directive are considered for the next stage.

(Absent “listen”, or “listen” without both a port and address, assume
the default values for the missing parts.)

After that, the server_name is considered, and the one best-match
server_name from the many best-match “listen” servers is chosen.

Is that any clearer? Can you suggest a wording for the manual that might
have made it clearer to you on first reading?

A consequence is that if you want every server{} to be potentially
considered for server_name matching for all requests, you must include
the same best-match “listen” directive in each server{}.

Thanks,

f

Francis D. [email protected]

On Thu, Jul 25, 2013 at 04:34:53AM -0400, drook wrote:

Thanks a lot, this is much clearer. Actually, ‘absent “listen”, or “listen”
without both a port and address, assume
the default values for the missing parts’ explains everything, and I think
the manual would be more clear mentioning this explicitly (still imo).

The documentation

http://nginx.org/en/docs/http/ngx_http_core_module.html#listen

says, in particular:

: If only address is given, the port 80 is used.
:
: If directive is not present then either the *:80 is used if nginx
: runs with superuser privileges, or *:8000 otherwise.

Actually, I’ve read carefully this part of the manual before creating
this
topic. I still think the quoted passage explains nothing about
virtualhost
handling. It doesn’t explain that skipping address or port will result
in
what I prefer to call “less prioritized vhosts”. May be it’s obvious
from
the parts you and Igor pointed at, but not to me, sorry.

I undrestood the concept (at least I think I did), so no further
questions
left - thanks. I think you don’t indend to discuss how to write the
documantation. :slight_smile:

Posted at Nginx Forum: