Re: proxy API compat break in 2.4.7
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 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
Re: proxy API compat break in 2.4.7
> On Apr 7, 2016, at 6:55 PM, Yann Ylavic wrote: > > On Thu, Apr 7, 2016 at 8:09 PM, Rainer Jung 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. > > Possibly [1] (currently proposed for backport) may cause the same issue. > We should probably fix it (ie. move the new fields to the end of > proxy_worker_shared) to make it backportable... > Yep, will need to adjust the patch.
Re: proxy API compat break in 2.4.7
On 04/07/2016 09:36 PM, William A Rowe Jr wrote: > 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. +1 Regards Rüdiger
Re: proxy API compat break in 2.4.7
Am 08.04.2016 um 00:55 schrieb Yann Ylavic: On Thu, Apr 7, 2016 at 8:09 PM, Rainer Jung 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. Possibly [1] (currently proposed for backport) may cause the same issue. We should probably fix it (ie. move the new fields to the end of proxy_worker_shared) to make it backportable... Regards, Yann. [1] http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy.h?r1=1667707&r2=1725545&diff_format=h Yes, fully agreed, as-is it would result in an API break. Rainer
Re: proxy API compat break in 2.4.7
On Thu, Apr 7, 2016 at 8:09 PM, Rainer Jung 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. Possibly [1] (currently proposed for backport) may cause the same issue. We should probably fix it (ie. move the new fields to the end of proxy_worker_shared) to make it backportable... Regards, Yann. [1] http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy.h?r1=1667707&r2=1725545&diff_format=h
Re: proxy API compat break in 2.4.7
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 mailto:rainer.j...@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
Re: proxy API compat break in 2.4.7
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 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 >
proxy API compat break in 2.4.7
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
