Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: proxy API compat break in 2.4.7
From: Jim Jagielski <jim@jaguNET.com>
In-Reply-To: <5706A254.5060105@kippdata.de>
Date: Fri, 8 Apr 2016 12:55:39 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <AF7EDD27-13FC-409D-8470-72A27329ED44@jaguNET.com>
References: <5706A254.5060105@kippdata.de>
To: dev@httpd.apache.org

Ahh... yes, for 3rd party modules depending on mod_proxy, or
using mod_proxy, they would need to be recompiled.

Ideally, we should have put these at the end of the struct
as we do with the more "major" structs.

> On Apr 7, 2016, at 2:09 PM, Rainer Jung <rainer.jung@kippdata.de> =
wrote:
>=20
> Revision 1560081 (backport of r1533087) introduced "char =
uds_path[PROXY_WORKER_MAX_NAME_SIZE]" in the middle of the =
proxy_worker_shared structure which IMHO broke compatibility between =
2.4.6 and 2.4.7.
>=20
> I noticed it just now, because I was implementing a custom LB method =
and during runtime it always found s->status to be 0. I had compiled it =
against an old 2.4.4 to ensure not using later features, but was testing =
inside 2.4.18. Thus the offset of the status field calculated for 2.4.4 =
actually pointed into the long uds_path string which wasn't used and =
probably calloced with zeroes.
>=20
> Any good idea how to best document the break for other module =
developers?
>=20
> Regards,
>=20
> Rainer