Where does $remote_addr come from?
reallfqq-nginx at yahoo.fr
Sat Feb 4 13:00:47 UTC 2017
I am curious: apart from a training prospective at code digging, what was
In other words, where did you expect the IP address to come from, if not
from a system network socket?
Have a nice week-end,
On Sat, Feb 4, 2017 at 12:02 AM, Paul Nickerson <pnickerson at cashstar.com>
> > Reading that file, the next likely looking line is:
> > c->addr_text.len = ngx_sock_ntop(c->sockaddr, c->socklen,
> > c->addr_text.data,
> > ls->addr_text_max_len, 0);
> Thank you for the boost. From what you said, it looks like the variable is
> constructed from c->sockaddr
> line 167
> c->sockaddr = ngx_palloc(c->pool, socklen);
> I chased that down, and it looks like ngx_palloc only allocates some
> memory; it doesn't fill it. Moving on.
> line 173
> ngx_memcpy(c->sockaddr, &sa, socklen);
> It looks like ngx_memcpy is a wrapper around the standard C library
> function memcpy. For memcpy(A, B, C), it copies to destination A from
> source B, and it does amount C. So now I want to know where &sa comes from.
> line 70
> s = accept(lc->fd, &sa.sockaddr, &socklen);
> Here, &sa.sockaddr is being sent into something. I think &sa.sockaddr
> becomes c->sockaddr, so I chase this.
> man 2 accept
> accept is a Linux system call: "accept a connection on a socket"
> int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
> "The argument addr is a pointer to a sockaddr structure. This
> structure is filled in with the address of the peer socket, as known
> to the communications layer. The exact format of the address
> returned addr is determined by the socket's address family (see
> socket(2) and the respective protocol man pages). When addr is NULL,
> nothing is filled in; in this case, addrlen is not used, and should
> also be NULL."
> And so, the answer to my question appears to be: $remote_addr is
> constructed from "struct sockaddr *addr" of the "accept" Linux system call.
> It is the address of the peer socket.
> I am going to read through socket(2) and the respective protocol man
> pages, but at this point we're outside of NGINX, and so the scope of this
> mailing list.
> Thank you again for your help.
> ~ Paul Nickerson
> *CONFIDENTIALITY NOTICE*
> The attached information is PRIVILEGED AND CONFIDENTIAL and is intended
> only for the use of the addressee named above. If the reader of this
> message is not the intended recipient or the employee or agent responsible
> for delivering the message to the intended recipient, please be aware that
> any dissemination, distribution or duplication of this communication is
> strictly prohibited. If you receive this communication in error, please
> notify us immediately by telephone, delete the message and destroy any
> printed copy of the message. Thank you.
> nginx mailing list
> nginx at nginx.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nginx