Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Subject: Re: proxy API compat break in 2.4.7
To: dev@httpd.apache.org
References: <5706A254.5060105@kippdata.de>
 <CACsi253bg=roJD86X+99yqaJPFZ6yhxowrYA=TXsLmC-NXr6cA@mail.gmail.com>
From: Rainer Jung <rainer.jung@kippdata.de>
Message-ID: <5706BD6A.7080508@kippdata.de>
Date: Thu, 7 Apr 2016 22:04:58 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: 
 <CACsi253bg=roJD86X+99yqaJPFZ6yhxowrYA=TXsLmC-NXr6cA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Thanks, fully agreed. I added short notes in r1738184.

Regards,

Rainer

Am 07.04.2016 um 21:36 schrieb William A Rowe Jr:
> The first most important documentation of this should be in ap_mmn.h,
> as we've done in the past (you'll see some highlights).
>
> A note under the CHANGES entry for 2.4.7 seems worthwhile.
>
> Pointing this out under Announcement seems appropriate, that users
> of third party mod_proxy-consuming modules will need to recompile
> those modules when upgrading from 2.4.1 - 2.4.6.
>
> I can't think of another obvious place, other than any related doxygen.
>
> It seems to late to correct this situation, as half the world will benefit
> from leaving things as they are, and the other half of the world would
> have an easier time migrating from 2.4.early to 2.4.now.  Lose lose
> situation in my mind, so best to leave as-is, with docs.
>
>
>
> On Thu, Apr 7, 2016 at 1:09 PM, Rainer Jung <rainer.jung@kippdata.de
> <mailto:rainer.jung@kippdata.de>> wrote:
>
>     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.
>
>     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.
>
>     Any good idea how to best document the break for other module
>     developers?
>
>     Regards,
>
>     Rainer