Nginx forum returns 502 (2014-03-25T08:13Z)

Bruno Prémont bruno.premont at
Wed Mar 26 14:10:03 UTC 2014

On Wed, 26 Mar 2014 14:56:09 +0100 B.R. wrote:
> Thanks Jonathan for the pointer. I was going to throw some WIkipedia page
> about it but RFC is definitely the best!
> I am glad you discovered I was not alone Jim, thought I am a little sad
> that you were that harsh welcoming my input as, if I may, I also did the
> reporting on my free time, and without it I am unsure whether you would
> have investigated anything?
> On a side note, I know what working for free in whatever structure is. I
> just rarely used that as an excuse to take the right of sending people of
> good faith away.
> I do not know if those 502 are directly tied to some IPv6 request, since I
> have both v4/v6 connectivity. I do not know how switch/fallback between
> versions occur during normal browsing.
> I recovered access to the URL, but following your explanation the 502 were
> due to the temporary apache setup.
> - I know little about Apache and especially RPAF module, but Googling a
> little around I found that:
> I do not know if that would help, but who knows? If you are using Debian,
> it seems there was an update at the end of January.

Yeah, vanilla mod_rpaf-0.6 does not handle IPv6 addresses well.

Be careful with the patch you choose, some fix the textual
representation of REMOTE_ADDR but still break on Apache-side access
control (e.g. on mis-match between proxy connection address family and
header-passed address family).

The patch I'm using successfully here is inlined below.


> - For PHP stopping accepting requests, since it is not crashing and you
> confirm the traffic volume is high, I would bet on the exhaustion of
> threads being able to accept new requests. Looks like the usual symptoms.
> Ironically, I found some answers on the Nginx ML archive that would help
> improving threads pool and PHP jobs execution time limit:
> I hope you will find your way out of there,

diff -NurpP a/mod_rpaf.c b/mod_rpaf.c
--- a/mod_rpaf.c	2014-02-17 09:21:08.278411786 +0100
+++ b/mod_rpaf.c	2014-02-17 10:20:18.083940819 +0100
@@ -173,6 +173,7 @@ static int change_remote_ip(request_rec
         if (fwdvalue) {
+            apr_sockaddr_t *tmpsa;
             rpaf_cleanup_rec *rcr = (rpaf_cleanup_rec *)apr_pcalloc(r->pool, sizeof(rpaf_cleanup_rec));
             apr_array_header_t *arr = apr_array_make(r->pool, 0, sizeof(char*));
             while (*fwdvalue && (val = ap_get_token(r->pool, &fwdvalue, 1))) {
@@ -184,7 +185,8 @@ static int change_remote_ip(request_rec
             rcr->r = r;
             apr_pool_cleanup_register(r->pool, (void *)rcr, rpaf_cleanup, apr_pool_cleanup_null);
             r->connection->remote_ip = apr_pstrdup(r->connection->pool, ((char **)arr->elts)[((arr->nelts)-1)]);
-            r->connection->remote_addr->sa.sin.sin_addr.s_addr = apr_inet_addr(r->connection->remote_ip);
+            if (apr_sockaddr_info_get(&tmpsa, r->connection->remote_ip, APR_UNSPEC, r->connection->remote_addr->port, 0, r->connection->remote_addr->pool) == APR_SUCCESS)
+                memcpy(r->connection->remote_addr, tmpsa, sizeof(apr_sockaddr_t));
             if (cfg->sethostname) {
                 const char *hostvalue;
                 if ((hostvalue = apr_table_get(r->headers_in, "X-Forwarded-Host"))) {

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mod_rpaf-0.6-ipv6.patch
Type: text/x-patch
Size: 1371 bytes
Desc: not available
URL: <>

More information about the nginx mailing list