Re: Binary Breakage (was: svn commit: r1824592 - /httpd/httpd/branches/2.4.x/STATUS)

[William A Rowe Jr]

On Wed, Feb 21, 2018 at 12:50 AM, Plüm, Rüdiger, Vodafone Group
 wrote:
>
>> -Ursprüngliche Nachricht-
>> Von: William A Rowe Jr [mailto:wr...@rowe-clan.net]
>> Gesendet: Dienstag, 20. Februar 2018 22:29
>> An: httpd 
>> Betreff: Re: Binary Breakage (was: svn commit: r1824592 -
>> /httpd/httpd/branches/2.4.x/STATUS)
>>
>> On Tue, Feb 20, 2018 at 2:57 PM, Ruediger Pluem 
>> wrote:
>> >
>> > On 02/20/2018 09:39 PM, William A Rowe Jr wrote:
>> >
>> >> Moving a member in a well-defined structure doesn't fall into this
>> >> generally accepted change (expanding the length of a struct.)
>> >> Consider the shm array change doesn't fall into the "it is just
>> >> a longer struct" example.
>> >
>> > Can you please give me a pointer which shm array change you are
>> referring to?
>>
>> r1824504
>
> Thanks.
>
> What particular breakage are you referring to in the above revision?
> As far as I can tell, the bug does not get fixed for modules that do not use 
> the new field, but it doesn't break them.

Again (I think I commented and this was pointed out on list) that
mod_cluster is broken. However, mod_cluster is broken in the sense
that it rearranges members of the array, and without knowledge of
the future size of the struct, it ultimately fails to succeed.

Modules like mod_ftp and mod_cluster and mod_wsgi and ... these that
assume the role of core functions and believe they know the size of a
future structure, they can't be kept portable. So if earlier comments
about mod_cluster are correct, I am taking this exception as a
mutual-failure scenario of compatibility.

Therefore the proxy balancer scoreboard, for display purposes, should
not cause faults (although the data won't be correct beyond existing
field sizes.) And, for manipulation, no module that deals in the
affected fields will still function. If you believe that
mod_proxy_balancer exists solely for httpd-project implemented
providers, this is not an issue; I continue to vote no position on the
untenable abuse of the 2.4 ABI.

Cheers,

Bill

AW: svn commit: r1824592 - /httpd/httpd/branches/2.4.x/STATUS

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Joe Orton [mailto:jor...@redhat.com]
> Gesendet: Dienstag, 20. Februar 2018 09:20
> An: dev@httpd.apache.org
> Betreff: Re: svn commit: r1824592 - /httpd/httpd/branches/2.4.x/STATUS
> 
> On Mon, Feb 19, 2018 at 08:38:05PM +0100, Ruediger Pluem wrote:
> > On 02/19/2018 07:50 PM, Joe Orton wrote:
> > > On Sat, Feb 17, 2018 at 02:06:20PM -, minf...@apache.org wrote:
> > >> Author: minfrin
> > >> Date: Sat Feb 17 14:06:20 2018
> > >> New Revision: 1824592
> > >>
> > >> URL: http://svn.apache.org/viewvc?rev=1824592=rev
> > >> Log:
> > >> Update proposal with fix for rpluem/jorton.
> > >
> > > Extending dav_resource still breaks binary backards compat with
> all(?)
> > > consumers of this API, or am I missing something here?
> >
> > I don't think so. Modules that just work with pointers to structs
> created by mod_dav shouldn't
> > have any issues, but see below.
> 
> Looking again, I think the way the mod_dav API is designed does make it
> necessary for consumers of the API to allocate dav_resource structures.
> There are a number of hooks like ->get_resource():
> 
> dav_error * (*get_resource)(
> request_rec *r,
> const char *root_dir,
> const char *label,
> int use_checked_in,
> dav_resource **resource
> );
> 
> ... which are implemented in repos providers which must allocate that
> *resource, and hence changing sizeof(dav_resource) will break binary BC,
> even if the structure was not embedded anywhere.
> 
> > > Look at what mod_dav_svn does with the struct for an example:
> > >
> https://svn.apache.org/viewvc/subversion/trunk/subversion/mod_dav_svn/re
> pos.c?view=markup#l80
> >
> > I guess this gets us back to this _copy / _sizeof discussion we had in
> another thread recently.
> > Creating structures / allocating memory for them in modules is IMHO a
> recipe to fail with our current
> > backporting policy as we allow to extend structures at the end.
> 
> Yup.
>
> In this case would moving ->acls and ->ctx to a pool note of the ->pool 
> field (actually is ->ctx actually used??) might work to preserve BC?

Having reviewed the above more closely and letting it sink in I just voted -1
for this backport proposal (r1824928).
I think it would not be fair to let the consumers of the mod_dav API pay the 
price
for a conflict between its API design and our backporting rules that we have 
created.
Let's fix this up in trunk for the next major release (either in the mod_dav 
API directly
or by providing appropriate helpers for creating / allocating / copying such 
structs as
discussed in the other thread.)
Note that this is no general -1 on the ACL extension, but on the way we add it 
to the
existing API in 2.4.x (no -1 on the respective trunk revision). If we find 
another way
to bring it in (e.g. as outlined above) I am fine. But we should probably let 
people
know upfront that this API interface is subject to change in the next major 
release.

Regards

Rüdiger

AW: Binary Breakage (was: svn commit: r1824592 - /httpd/httpd/branches/2.4.x/STATUS)

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: William A Rowe Jr [mailto:wr...@rowe-clan.net]
> Gesendet: Dienstag, 20. Februar 2018 22:29
> An: httpd 
> Betreff: Re: Binary Breakage (was: svn commit: r1824592 -
> /httpd/httpd/branches/2.4.x/STATUS)
> 
> On Tue, Feb 20, 2018 at 2:57 PM, Ruediger Pluem 
> wrote:
> >
> > On 02/20/2018 09:39 PM, William A Rowe Jr wrote:
> >
> >> Moving a member in a well-defined structure doesn't fall into this
> >> generally accepted change (expanding the length of a struct.)
> >> Consider the shm array change doesn't fall into the "it is just
> >> a longer struct" example.
> >
> > Can you please give me a pointer which shm array change you are
> referring to?
> 
> r1824504

Thanks.

What particular breakage are you referring to in the above revision?
As far as I can tell, the bug does not get fixed for modules that do not use 
the new field, but it doesn't break them.

Regards

Rüdiger

Re: [VOTE] Release Apache httpd 2.4.26 as GA

[Eric Covener]

On Tue, Jun 13, 2017 at 10:05 PM, Eric Covener  wrote:
> +1 AIX/xlc/ppc64
>
> I have two quirks to record, both are openssl / openssl 1.1 related
> but given the state of my AIX system I am still +1 on the release.
>
>  - proxy/ssl.t almost totally fails with handhsake errors between
> client and origin
> [Tue Jun 13 21:37:04.265062 2017] [ssl:info] [pid 15073386:tid 6169]
> SSL Library Error: error:14171105:SSL
> routines:tls_process_server_hello:wrong cipher returned
>
> - There is some kind of atexit()-like issue with unloaded openssl-1.1
> that causes a SIGILL at shutdown (goes away w/o mod_ssl, is not
> related to signal handling thing)
> .() at 0x0
> exit(??) at 0x90550c0
> destroy_and_exit_process(process = 0x00011001eb28,
> process_exit_value = 0), line 266 in "main.c"
> main(argc = 4, argv = 0x07c8), line 685 in "main.c"

(replying to old vote thread for posterity)

TIL:
 - linux calls atexit() callbacks when a library is unloaded, not just
at process exit
 - AIX doesn't
 - openssl 1.1 adds an atexit handler
 - openssl 1.1 has some code to try to prevent the library from really
being unloaded by inflating the dlopen reference count so its atexit
will really be available at exit.
- https://github.com/openssl/openssl/pull/1693
-  apparently this isn't working on AIX
 - openssl 1.1 doesn't seem to be provided by IBM or third parties on
AIX as of early 2018.








-- 
Eric Covener
cove...@gmail.com

Re: [VOTE] Release httpd-2.4.30

[Rainer Jung]

Am 19.02.2018 um 15:54 schrieb drugg...@primary.net:

Hi, all;

    Please find below the proposed release tarball and signatures:

https://dist.apache.org/repos/dist/dev/httpd/

I would like to call a VOTE over the next few days to release this 
candidate tarball as 2.4.30:


[ ] +1: It’s not just good, it’s good enough!

[ ] +0: Let’s have a talk…

[ ] -1: There’s trouble in paradise. Here’s what’s wrong.


My testing is still ongoing but one thing I noticed: the dependency 
tarball which we provide for convenience still contains APR/APU 
1.6.2/1.6.0, but recent versions would be 1.6.3/1.6.1.


Regards,

Rainer

Re: win32: disable shared LDAP cache by default

[Eric Covener]

whoops, http://svn.apache.org/viewvc?view=revision=1824811

On Tue, Feb 20, 2018 at 5:42 PM, William A Rowe Jr  wrote:
> Which patch? I think you are missing a digit.
>
> On Mon, Feb 19, 2018 at 5:57 PM, Eric Covener  wrote:
>> I am hoping this is fixed by
>> http://svn.apache.org/viewvc?view=revision=182481 which I
>> stumbled onto from another direction.
>>
>> On Thu, Aug 3, 2017 at 5:58 AM, Stefan Sperling  wrote:
>>> There are numerous reports of Apache HTTPD looping forever on Windows
>>> unless the LDAPSharedCacheSize option is set to zero.
>>>
>>> See for instance:
>>> https://svn.haxx.se/users/archive-2014-05/.shtml
>>> https://subversion.open.collab.net/ds/viewMessage.do?dsMessageId=564176=3
>>> https://subversion.open.collab.net/ds/viewMessage.do?dsForumId=3=browseAll=539507
>>> https://stackoverflow.com/questions/44542654/collabnet-subversion-server-reaching-cpu-100-because-of-httpd-exe-process
>>>
>>> I looked around for a while but don't know yet if a corresponding issue
>>> in the HTTPD bug tracker exists. Does anyone know?
>>>
>>> On the surface it looks like a memory pool corruption bug to me.
>>> The stack trace posted in 
>>> https://svn.haxx.se/users/archive-2014-05/.shtml
>>> points towards an endless loop in apr_pool_cleanup_kill().
>>> The trace ends at APR-util's 
>>> misc/apr_reslist.c:apr_reslist_cleanup_order_set,
>>> and of the functions this calls only apr_pool_cleanup_kill() contains loops.
>>>
>>> I could not do any further debugging since I only had a production setup
>>> to look at, which is stable with the workaround 'LDAPSharedCacheSize 0'.
>>> I also do not have a Windows dev environment and I don't plan on digging
>>> any further.
>>>
>>> Until the real bug gets found and fixed, I would recommend making the
>>> known workaround the default on Windows. Because the winnt MPM runs a
>>> single process, there is no benefit to a shared memory cache anyway.
>>>
>>> Should I commit this patch?
>>>
>>> Index: modules/ldap/util_ldap.c
>>> ===
>>> --- modules/ldap/util_ldap.c(revision 1803972)
>>> +++ modules/ldap/util_ldap.c(working copy)
>>> @@ -2815,7 +2815,17 @@ static void *util_ldap_create_config(apr_pool_t *p
>>>  apr_thread_mutex_create(>mutex, APR_THREAD_MUTEX_DEFAULT, 
>>> st->pool);
>>>  #endif
>>>
>>> +#ifdef WIN32
>>> +/* XXX The shared memory cache can cause an endless loop on Windows.
>>> + * See https://svn.haxx.se/users/archive-2014-05/.shtml and
>>> + * similar reports elsewhere which recommend 'LDAPSharedCacheSize 0'
>>> + * as a workaround.
>>> + * Because the winnt MPM uses a single process a shared cache is
>>> + * not needed anyway so leave it disabled by default. */
>>> +st->cache_bytes = 0;
>>> +#else
>>>  st->cache_bytes = 50;
>>> +#endif
>>>  st->search_cache_ttl = 6;
>>>  st->search_cache_size = 1024;
>>>  st->compare_cache_ttl = 6;
>>
>>
>>
>> --
>> Eric Covener
>> cove...@gmail.com



-- 
Eric Covener
cove...@gmail.com

Re: win32: disable shared LDAP cache by default

[William A Rowe Jr]

Which patch? I think you are missing a digit.

On Mon, Feb 19, 2018 at 5:57 PM, Eric Covener  wrote:
> I am hoping this is fixed by
> http://svn.apache.org/viewvc?view=revision=182481 which I
> stumbled onto from another direction.
>
> On Thu, Aug 3, 2017 at 5:58 AM, Stefan Sperling  wrote:
>> There are numerous reports of Apache HTTPD looping forever on Windows
>> unless the LDAPSharedCacheSize option is set to zero.
>>
>> See for instance:
>> https://svn.haxx.se/users/archive-2014-05/.shtml
>> https://subversion.open.collab.net/ds/viewMessage.do?dsMessageId=564176=3
>> https://subversion.open.collab.net/ds/viewMessage.do?dsForumId=3=browseAll=539507
>> https://stackoverflow.com/questions/44542654/collabnet-subversion-server-reaching-cpu-100-because-of-httpd-exe-process
>>
>> I looked around for a while but don't know yet if a corresponding issue
>> in the HTTPD bug tracker exists. Does anyone know?
>>
>> On the surface it looks like a memory pool corruption bug to me.
>> The stack trace posted in 
>> https://svn.haxx.se/users/archive-2014-05/.shtml
>> points towards an endless loop in apr_pool_cleanup_kill().
>> The trace ends at APR-util's 
>> misc/apr_reslist.c:apr_reslist_cleanup_order_set,
>> and of the functions this calls only apr_pool_cleanup_kill() contains loops.
>>
>> I could not do any further debugging since I only had a production setup
>> to look at, which is stable with the workaround 'LDAPSharedCacheSize 0'.
>> I also do not have a Windows dev environment and I don't plan on digging
>> any further.
>>
>> Until the real bug gets found and fixed, I would recommend making the
>> known workaround the default on Windows. Because the winnt MPM runs a
>> single process, there is no benefit to a shared memory cache anyway.
>>
>> Should I commit this patch?
>>
>> Index: modules/ldap/util_ldap.c
>> ===
>> --- modules/ldap/util_ldap.c(revision 1803972)
>> +++ modules/ldap/util_ldap.c(working copy)
>> @@ -2815,7 +2815,17 @@ static void *util_ldap_create_config(apr_pool_t *p
>>  apr_thread_mutex_create(>mutex, APR_THREAD_MUTEX_DEFAULT, st->pool);
>>  #endif
>>
>> +#ifdef WIN32
>> +/* XXX The shared memory cache can cause an endless loop on Windows.
>> + * See https://svn.haxx.se/users/archive-2014-05/.shtml and
>> + * similar reports elsewhere which recommend 'LDAPSharedCacheSize 0'
>> + * as a workaround.
>> + * Because the winnt MPM uses a single process a shared cache is
>> + * not needed anyway so leave it disabled by default. */
>> +st->cache_bytes = 0;
>> +#else
>>  st->cache_bytes = 50;
>> +#endif
>>  st->search_cache_ttl = 6;
>>  st->search_cache_size = 1024;
>>  st->compare_cache_ttl = 6;
>
>
>
> --
> Eric Covener
> cove...@gmail.com

Re: Binary Breakage (was: svn commit: r1824592 - /httpd/httpd/branches/2.4.x/STATUS)

[William A Rowe Jr]

On Tue, Feb 20, 2018 at 3:43 PM, Yann Ylavic  wrote:
> On Tue, Feb 20, 2018 at 10:29 PM, William A Rowe Jr  
> wrote:
>> On Tue, Feb 20, 2018 at 2:57 PM, Ruediger Pluem  wrote:
>>>
>>> On 02/20/2018 09:39 PM, William A Rowe Jr wrote:
>>>
 Moving a member in a well-defined structure doesn't fall into this
 generally accepted change (expanding the length of a struct.)
 Consider the shm array change doesn't fall into the "it is just
 a longer struct" example.
>>>
>>> Can you please give me a pointer which shm array change you are referring 
>>> to?
>>
>> r1824504
>
> I'm not sure it falls outside our guarantees, the old "hostname" field
> is still there (at the same place) and populated.

NUL \0 delimited? Cool.

Provided mod_status and mod_cluster 2.4.29 won't crash,
*for display purposes* we can agree that isn't a concern.
(mod_cluster updates will crash and we can agree that was
extending the API contract to an unrealistic bounds.)

Bill

Re: svn commit: r25136 - /release/httpd/flood/

[William A Rowe Jr]

Speaking of, are these needed, or should we create attic/ ?

http://svn.apache.org/repos/asf/httpd/flood/
http://svn.apache.org/repos/asf/httpd/mod_spdy/
http://svn.apache.org/repos/asf/httpd/mod_wombat/

and most content within http://svn.apache.org/viewvc/httpd/sandbox/
(as a sandbox/attic/)?

I am somewhat confused as to the state of
http://svn.apache.org/repos/asf/httpd/apreq/ since I see no dev@
traffic relative to this branch, but it was previously slated for core
inclusion in httpd.next, and I'm unclear whether trunk is in-sync.

Cheers,

Bill


On Mon, Feb 19, 2018 at 2:24 AM,   wrote:
> Author: humbedooh
> Date: Mon Feb 19 08:24:18 2018
> New Revision: 25136
>
> Log:
> Removing flood...
>
> Removed:
> release/httpd/flood/
>

Re: Binary Breakage (was: svn commit: r1824592 - /httpd/httpd/branches/2.4.x/STATUS)

[Yann Ylavic]

On Tue, Feb 20, 2018 at 10:29 PM, William A Rowe Jr  wrote:
> On Tue, Feb 20, 2018 at 2:57 PM, Ruediger Pluem  wrote:
>>
>> On 02/20/2018 09:39 PM, William A Rowe Jr wrote:
>>
>>> Moving a member in a well-defined structure doesn't fall into this
>>> generally accepted change (expanding the length of a struct.)
>>> Consider the shm array change doesn't fall into the "it is just
>>> a longer struct" example.
>>
>> Can you please give me a pointer which shm array change you are referring to?
>
> r1824504

I'm not sure it falls outside our guarantees, the old "hostname" field
is still there (at the same place) and populated.

Re: Binary Breakage (was: svn commit: r1824592 - /httpd/httpd/branches/2.4.x/STATUS)

[William A Rowe Jr]

On Tue, Feb 20, 2018 at 3:28 PM, Yann Ylavic  wrote:
>
> This probably does not apply to 2.4.x (as a strong statement), in the
> meantime we at least need the helpers and give a hand at updating the
> modules, if we can't avoid extending our own structs...

I agree this discussion, outside of an interesting balancer shm
change and proposed mod_dav enhancement change, should
be largely status-quo.

I will go so far as to veto the idea of backporting the helpers to 2.4.
We cannot avoid admitting our errors in design of that released
branch, and papering over them now accomplishes little. At best
it would require an mmn check and only optionally consider their
use at runtime, with no hard linkage, since such modules can't
be loaded in earlier 2.4.x httpd releases.

Decide our fixes for rev.next and make that available for authors
to have a much easier time keeping binary compatibility with us,
even in deep intrinsic structures as you hint at.

One way to do this is to rev specific structure definitions... if the
module wants to break over the way they customized their
interaction with the structure or its indirection to members
(e.g. const/non-const changes) then let them do that at the
structure-relevant revision.

Re: Licensing claims (pcreposix)

[Yann Ylavic]

On Tue, Feb 20, 2018 at 10:27 PM, William A Rowe Jr  wrote:
>
> Any objections?

+1

Re: Binary Breakage (was: svn commit: r1824592 - /httpd/httpd/branches/2.4.x/STATUS)

[William A Rowe Jr]

On Tue, Feb 20, 2018 at 2:57 PM, Ruediger Pluem  wrote:
>
> On 02/20/2018 09:39 PM, William A Rowe Jr wrote:
>
>> Moving a member in a well-defined structure doesn't fall into this
>> generally accepted change (expanding the length of a struct.)
>> Consider the shm array change doesn't fall into the "it is just
>> a longer struct" example.
>
> Can you please give me a pointer which shm array change you are referring to?

r1824504

Re: Binary Breakage (was: svn commit: r1824592 - /httpd/httpd/branches/2.4.x/STATUS)

[Yann Ylavic]

On Tue, Feb 20, 2018 at 9:39 PM, William A Rowe Jr  wrote:
> On Tue, Feb 20, 2018 at 2:24 PM, Ruediger Pluem  wrote:
>>
>> 1. We continue as we do now and allow extending structures at the end. We 
>> should probably document more prominently that
>> copying / allocating / creating public structures is not allowed and if done 
>> can require minor version specific recompiling.
>
[]
>
> The proposed mod_dav case is worse yet. If we accept that the
> API demands the submodule pass the struct to mod_dav, there
> is no way to distinguish what is going on, and whether this module
> was written for 2.4.27 or 2.4.33. Worse 2x yet, we guaranteed that
> no source code revision would be required during 2.4.x.

The issue is that there is nothing we can do for the mod_dav case
(besides not extending the struct at all).
Neither _sizeof nor _copy would address that, if a module struct
compounds an ap_xxx_rec something anywhere but at the end then bets
are off (not to talk about this struct being used as a persised file
record).
How to statically define such a struct when _sizeof() is a function?
Offsets make using less friendly to use at runtime too...

We possibly need to exclude compound structs from our ABI garantees.

>
>> 2. We stop allowing extending structures at the end on stable branches.
>
> I don't think that is realistic. Adding a new member with an acceptable
> NULL/unknown purpose, and adding 3) as noted below, should
> generally solve for the case of "module which must be recompiled
> on each release".

I hope we won't do 2., or we may need to release a major version quite
often (which wouldn't help module authors either).

>
>> 3. Like 1., but we add _sizeof / _copy functions for each public struct as 
>> discussed in the other thread, make the
>> existence of the functions mandatory for every new public struct and advice 
>> module authors that they need to leverage
>> them if the want to copy / allocate / create these structures in their 
>> modules.
>>
>> We can do 1., 2. or 3. now or set this as the rule for the next major 
>> release.
>
> The advantage to _sizeof/_copy and enforcing the "new member
> default must be ok-to-be-NULL" rule means that mod_cluster,
> mod_ftp, mod_wsgi and many many other edge-case modules
> don't need to be recompiled. This situation can be dramatically
> improved in 2.next/3.0. Ensuring _create() accessors are always
> provided and demanded to initialize everything that shouldn't
> default to NULL is the 100% solve.

I'm fine with 1 and 3, and would like that we don't guarantee ABI
stability for compound structs or persisted files with our structs as
record, such constructions should use 3. with runtime tricks (in the
first place, IMHO).
This probably does not apply to 2.4.x (as a strong statement), in the
meantime we at least need the helpers and give a hand at updating the
modules, if we can't avoid extending our own structs...


Regards,
Yann.

Licensing claims (pcreposix)

[William A Rowe Jr]

I made a fundamental mistake as we removed PCRE from
the source tree of httpd; although we stopped distributing the
pcre library in 2.4.x source tree, our own util_pcre.c is largely
founded on the work of Philip Hazel/Cambridge; although the
larger work doesn't need to be advertised in our LICENSE and
NOTICE (except in the case of binaries derived from those
sources, which is up to the packager/builder), the origin of this
specific source file remains largely based on pcreposix.c.

We can later ask for a relicensing by the PCRE effort, or we
may agree to license that entire file, including our corrections
and enhancements back under this compatible license. Since
it is largely pcre's own license, I would like to keep them in
harmony but not keep this file under a bifurcated license.
I ran into the same headache with my complete rewrite of
the fnmatch.c logic of BSD that we ship in APR, and delivered
my rewrite of the file under both licenses.

I have the attached proposal to correct this in trunk for any
immediate release on the 2.4.x branch, and would open a
dialog with Philip and Cambridge over their preferred manner
of handling this file. Cambridge may already have a statement
on simplifying the advertising aspects, much like MIT.

Any objections?
Index: LICENSE
===
--- LICENSE	(revision 1824908)
+++ LICENSE	(working copy)
@@ -322,6 +322,40 @@
  * WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES.  
  */
 
+
+For the util_pcre.c and ap_regex.h components:
+
+   Copyright (c) 1997-2004 University of Cambridge
+
+-
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are met:
+
+* Redistributions of source code must retain the above copyright notice,
+  this list of conditions and the following disclaimer.
+
+* Redistributions in binary form must reproduce the above copyright
+  notice, this list of conditions and the following disclaimer in the
+  documentation and/or other materials provided with the distribution.
+
+* Neither the name of the University of Cambridge nor the names of its
+  contributors may be used to endorse or promote products derived from
+  this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGE.
+-
+
+
 For the  srclib\apr\include\apr_md5.h component: 
 /*
  * This is work is derived from material Copyright RSA Data Security, Inc.
Index: NOTICE
===
--- NOTICE	(revision 1824908)
+++ NOTICE	(working copy)
@@ -12,3 +12,7 @@
 Inc. MD5 Message-Digest Algorithm, including various
 modifications by Spyglass Inc., Carnegie Mellon University, and
 Bell Communications Research, Inc (Bellcore).
+
+This software contains code derived from the PCRE library pcreposix.c
+source code, written by Philip Hazel, Copyright 1997-2004
+by the University of Cambridge, England.
Index: include/ap_regex.h
===
--- include/ap_regex.h	(revision 1824908)
+++ include/ap_regex.h	(working copy)
@@ -14,7 +14,12 @@
  * limitations under the License.
  */
 
-/* Derived from PCRE's pcreposix.h.
+/* This code is based on pcreposix.h from the PCRE Library distribution,
+ * as originally written by Philip Hazel , and forked by
+ * the Apache HTTP Server project to provide POSIX-style regex function
+ * wrappers around underlying PCRE library functions for httpd.
+ * 
+ * The original source file pcreposix.h is copyright and licensed as follows;
 
 Copyright (c) 1997-2004 University of Cambridge
 
Index: server/util_pcre.c
===
--- server/util_pcre.c	(revision 1824908)
+++ server/util_pcre.c	(working copy)
@@ -1,17 +1,26 @@
-/*
- *  Perl-Compatible Regular Expressions  *
- */
+/* Licensed to the Apache Software Foundation (ASF) 

Re: Binary Breakage (was: svn commit: r1824592 - /httpd/httpd/branches/2.4.x/STATUS)

[Ruediger Pluem]

On 02/20/2018 09:39 PM, William A Rowe Jr wrote:

> Moving a member in a well-defined structure doesn't fall into this
> generally accepted change (expanding the length of a struct.)
> Consider the shm array change doesn't fall into the "it is just
> a longer struct" example.
> 

Can you please give me a pointer which shm array change you are referring to?

Regards

Rüdiger

Re: Binary Breakage (was: svn commit: r1824592 - /httpd/httpd/branches/2.4.x/STATUS)

[William A Rowe Jr]

On Tue, Feb 20, 2018 at 2:24 PM, Ruediger Pluem  wrote:
>
> On 02/20/2018 08:20 PM, William A Rowe Jr wrote:
>
>> In other words, modules from one STABLE release to another ARE binary
>> compatible and do NOT need to be recompiled.
>>
>>
>> This is clearly not true of several recent changes, even though they
>> impact relatively few third party modules.
>>
>> I suggest that since the majority here accepted binary breakage as OK,
>
> I do not think that this is the case. I do not accept this and I don't think 
> the majority here does.
> I am around here for quite a while (effectively shortly before 2.2.x lifted 
> off)
> and it was always allowed to extend structures at the end. This was always 
> seen
> as a minor bump and within the set of allowed changes to a minor release.
> I don't know when these rules were decided, but I grew up with that tribal 
> knowledge
> and we have a long number of precedent cases for these changes on stable 
> branches.
> This is not something that was introduced recently.
> Having said that I admit that it does not match the statement that
> modules do not need to be recompiled once they have been compiled against a 
> major version
> and that they should run without the need to recompile against higher minor 
> versions
> (not necessarily lower ones as they might use added API's).
> Given that the question to me is how we move forward:
>
> 1. We continue as we do now and allow extending structures at the end. We 
> should probably document more prominently that
> copying / allocating / creating public structures is not allowed and if done 
> can require minor version specific recompiling.

Some structures may be extended and always introduce breakage
when a module chooses to copy the structure themself. mod_ftp
and mod_cluster are two examples of this.

In the case of mod_cluster, it depends on the location of members
of the structure, one of which just moved. We perturbed that module
with our member shift. BUT because it assumes it knows the len
of the structure, it made a bad assumption about doing this on the
behalf of a new core module. So it might be a reciprocal breakage.
Similarly, bad on mod_wsgi and mod_ftp and similar for creating
new structs who cannot predict the size; recompile them.

Moving a member in a well-defined structure doesn't fall into this
generally accepted change (expanding the length of a struct.)
Consider the shm array change doesn't fall into the "it is just
a longer struct" example.

The proposed mod_dav case is worse yet. If we accept that the
API demands the submodule pass the struct to mod_dav, there
is no way to distinguish what is going on, and whether this module
was written for 2.4.27 or 2.4.33. Worse 2x yet, we guaranteed that
no source code revision would be required during 2.4.x.

> 2. We stop allowing extending structures at the end on stable branches.

I don't think that is realistic. Adding a new member with an acceptable
NULL/unknown purpose, and adding 3) as noted below, should
generally solve for the case of "module which must be recompiled
on each release".

> 3. Like 1., but we add _sizeof / _copy functions for each public struct as 
> discussed in the other thread, make the
> existence of the functions mandatory for every new public struct and advice 
> module authors that they need to leverage
> them if the want to copy / allocate / create these structures in their 
> modules.
>
> We can do 1., 2. or 3. now or set this as the rule for the next major release.

The advantage to _sizeof/_copy and enforcing the "new member
default must be ok-to-be-NULL" rule means that mod_cluster,
mod_ftp, mod_wsgi and many many other edge-case modules
don't need to be recompiled. This situation can be dramatically
improved in 2.next/3.0. Ensuring _create() accessors are always
provided and demanded to initialize everything that shouldn't
default to NULL is the 100% solve.

The MMN minor does not help. Nothing suggests whether minor
.43 changes the size of any specific member *they* were depending
upon; modules may decide to throw up on load if they were compiled
against .42 and now are loaded into .43. But that doesn't answer the
question of whether something of importance to *that* module has
changed.

Re: Binary Breakage (was: svn commit: r1824592 - /httpd/httpd/branches/2.4.x/STATUS)

[Ruediger Pluem]

On 02/20/2018 08:20 PM, William A Rowe Jr wrote:

> 
> 
> In other words, modules from one STABLE release to another ARE binary
> compatible and do NOT need to be recompiled.
> 
> 
> This is clearly not true of several recent changes, even though they
> impact relatively few third party modules.
> 
> I suggest that since the majority here accepted binary breakage as OK,

I do not think that this is the case. I do not accept this and I don't think 
the majority here does.
I am around here for quite a while (effectively shortly before 2.2.x lifted off)
and it was always allowed to extend structures at the end. This was always seen
as a minor bump and within the set of allowed changes to a minor release.
I don't know when these rules were decided, but I grew up with that tribal 
knowledge
and we have a long number of precedent cases for these changes on stable 
branches.
This is not something that was introduced recently.
Having said that I admit that it does not match the statement that
modules do not need to be recompiled once they have been compiled against a 
major version
and that they should run without the need to recompile against higher minor 
versions
(not necessarily lower ones as they might use added API's).
Given that the question to me is how we move forward:

1. We continue as we do now and allow extending structures at the end. We 
should probably document more prominently that
copying / allocating / creating public structures is not allowed and if done 
can require minor version specific recompiling.
2. We stop allowing extending structures at the end on stable branches.
3. Like 1., but we add _sizeof / _copy functions for each public struct as 
discussed in the other thread, make the
existence of the functions mandatory for every new public struct and advice 
module authors that they need to leverage
them if the want to copy / allocate / create these structures in their modules.

We can do 1., 2. or 3. now or set this as the rule for the next major release.

Regards

Rüdiger

Binary Breakage (was: svn commit: r1824592 - /httpd/httpd/branches/2.4.x/STATUS)

[William A Rowe Jr]

On Mon, Feb 19, 2018 at 12:50 PM, Joe Orton  wrote:
> On Sat, Feb 17, 2018 at 02:06:20PM -, minf...@apache.org wrote:
>> Author: minfrin
>> Date: Sat Feb 17 14:06:20 2018
>> New Revision: 1824592
>>
>> URL: http://svn.apache.org/viewvc?rev=1824592=rev
>> Log:
>> Update proposal with fix for rpluem/jorton.
>
> Extending dav_resource still breaks binary backards compat with all(?)
> consumers of this API, or am I missing something here?
>
> Look at what mod_dav_svn does with the struct for an example:
> https://svn.apache.org/viewvc/subversion/trunk/subversion/mod_dav_svn/repos.c?view=markup#l80

(We can continue this from top-thread, but was this question
posed to or already considered by dev@svn?)

> If breaking backwards compat for module API is fine for 2.4 (and I'm
> still generally on the fence about this), I think it should at least be
> a "hard" break, e.g. by s/dav_register_provider/dav_register_provider2/.
> That way incompatible module combinations break at LoadModule time
> rather than with segfaults.

This is our Announcement policy;

   This release builds on and extends the Apache 2.2 API.  Modules written
   for Apache 2.2 will need to be recompiled in order to run with Apache
   2.4, and require minimal or no source code changes.

 http://svn.apache.org/repos/asf/httpd/httpd/trunk/VERSIONING

   When upgrading or installing this version of Apache, please bear in mind
   that if you intend to use Apache with one of the threaded MPMs (other
   than the Prefork MPM), you must ensure that any modules you will be
   using (and the libraries they depend on) are thread-safe.

Implication from the above, Modules written for Apache 2.4 will not need
to be recompiled in order to run with Apache 2.4.

Reading that linked document in reverse;

  DEVELOPMENT RELEASES, 2.{odd}.{revision}
  -

  All odd numbered releases designate the 'next' possible stable release,
  therefore the current development version will always be one greater than
  the current stable release.  Work proceeds on development releases, permitting
  the modification of the MMN at any time in order to correct deficiencies
  or shortcomings in the API.  This means that modules from one development
  release to another may not be binary compatible, or may not successfully
  compile without modification to accomodate the API changes.


In other words, modules from one STABLE release to another ARE binary
compatible and do NOT need to be recompiled.


This is clearly not true of several recent changes, even though they
impact relatively few third party modules.

I suggest that since the majority here accepted binary breakage as OK,
that the project at MINIMUM now documents every known third party
module that must be 1) modified in source or 2) recompiled for binary
breakage, and we place that full appendix in every Announcement, and
on the main httpd website announcement and download page (followed by
some "... and similar modules" caviet, since people may have forked
the logic from these third party examples.

Or I suggest we back out breaking changes and go back to what this
project previously agreed upon and promised for the lifespan of 2.4.x.
I don't believe we ever had unanimous consensus, the change to
ABI-strict versioning was a majority vote at the end of the day?
Changing that policy mid-version seems utterly stupid to me, but I'm
tired of people taking personal offense at -1's, so repeating what
I've said, I'm neither supporting nor opposing any 2.4.x changes.
Simply reminding the list of the basis for our policies.

Re: [VOTE] Release httpd-2.4.30

[William A Rowe Jr]

On Tue, Feb 20, 2018 at 6:06 AM, Jim Jagielski  wrote:
> -1: I think with the release process hiccups and the Win issues
> noted in the "Current branche 2.4.30-dev issues" thread,
> we will need a 2.4.31. Additionally, there are some
> backports in STATUS that could also be folded in.

Very sensible.

I think our odds of a successful 2.4.31 increase dramatically if the
community will please continue their 2.4.30 review as if it would
become the release. Hold off any re-spin for a couple days to allow
that to happen as it usually would.

If 2.4.31 remains relatively static vs. 2.4.30, it minimizes the number
of additional regressions, e.g. hold 2.4.x branch to showstoppers
or regression fixes of 2.4.29/2.4.30 only for a few days.

Reviewing a lightly modified 2.4.31 candidate becomes much
simpler if 2.4.30 candidate has been beaten on, sufficiently.

Re: More information about "Help Wanted" task

[Adesh Atole]

Hello,

I would also like to help and learn about the internals of httpd.

Thanks,
Adesh

On 20/02/2018, Prafulla  wrote:
> Hi,
>
> I found following page on apache's "Help Wanted" about httpd.
>
> https://helpwanted.apache.org/task.html?8de2fbaee4e9d2335083802882abe85940407f8d
>
> I would like to explore helping httpd project. I can program in
> c/c++/python.
> Can someone suggest how I should start about it?
> I have downloaded the code and I am going through it. If there is any
> easy/beginner task that I can take up, it would be good.
>
> --
> Thanks
> Prafulla
>
>
>

Re: svn commit: r1824887 - in /httpd/site/trunk/tools: push.sh tag.sh

[Jim Jagielski]

This is what I've been using:

#!/bin/sh
#

if test "$#" != 1; then
  echo "USAGE: $0 TAG" >&2
  exit 1
fi

svn copy -m "Tag HEAD of 2.4.x as $1" 
https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x 
https://svn.apache.org/repos/asf/httpd/httpd/tags/$1


> On Feb 20, 2018, at 10:17 AM, Yann Ylavic  wrote:
> 
> On Tue, Feb 20, 2018 at 3:33 PM,   wrote:
>> Author: druggeri
>> Date: Tue Feb 20 14:33:38 2018
>> New Revision: 1824887
>> 
>> URL: http://svn.apache.org/viewvc?rev=1824887=rev
>> Log:
>> Add some additional convenience tooling
>> 
>> Added:
> []
>>httpd/site/trunk/tools/tag.sh   (with props)
> []
>> 
>> Added: httpd/site/trunk/tools/tag.sh
>> URL: 
>> http://svn.apache.org/viewvc/httpd/site/trunk/tools/tag.sh?rev=1824887=auto
>> ==
>> --- httpd/site/trunk/tools/tag.sh (added)
>> +++ httpd/site/trunk/tools/tag.sh Tue Feb 20 14:33:38 2018
> []
>> +
>> +cd "$src_dir"
>> +#Set AP_SERVER_DEVBUILD_BOOLEAN to 0 in include/ap_release.h.
>> +perl -pi -e 's/(#define\s+AP_SERVER_DEVBUILD_BOOLEAN\s+)\d/${1}0/g' 
>> include/ap_release.h
>> +svn commit -m "Get ready to tag httpd $version"
>> +
>> +
>> +#Create an official X.Y.Z tag based on the candidate tree.
>> +svn copy "$src_dir" "$tags_dir/$version"
> 
> Could we use remote urls here to avoid local modifications mixture?
> Eg.: svn copy ^/httpd/httpd/branches/$branch ^/httpd/httpd/tags/$version
> The tag shouldn't (possibly) include anything not in the branch.
> 
> Regards,
> Yann.

Re: svn commit: r1824751 [1/2] - in /httpd/httpd/branches/2.4.x: ./ docs/manual/ docs/manual/mod/ include/

[Yann Ylavic]

On Tue, Feb 20, 2018 at 5:01 PM, Jim Jagielski  wrote:
> Useful links:
>
>   o http://svn.apache.org/viewvc?view=revision=1812440
>   o http://svn.apache.org/viewvc?view=revision=1812442
>
> These are easy to automate as well... I would suggest maybe 3
> scripts: pretag.sh (which readies the branch for tagging), tag.sh
> which does a simple svn cp and then posttag.sh which updates
> for the next round. Once the tag is created, we can use the
> existing release.sh to roll the tarballs and then your push.sh
> to move them to to dist.
>
> Having a set of small, single-purpose scripts that we chain
> together is nicer than a large script that tries to do it all,
> IMO.

+1, with this message as README :)

More information about "Help Wanted" task

[Prafulla]

Hi,

I found following page on apache's "Help Wanted" about httpd.

https://helpwanted.apache.org/task.html?8de2fbaee4e9d2335083802882abe85940407f8d

I would like to explore helping httpd project. I can program in c/c++/python.
Can someone suggest how I should start about it?
I have downloaded the code and I am going through it. If there is any 
easy/beginner task that I can take up, it would be good.

--
Thanks
Prafulla

Re: svn commit: r1824751 [1/2] - in /httpd/httpd/branches/2.4.x: ./ docs/manual/ docs/manual/mod/ include/

[Jim Jagielski]

Useful links:

  o http://svn.apache.org/viewvc?view=revision=1812440
  o http://svn.apache.org/viewvc?view=revision=1812442

These are easy to automate as well... I would suggest maybe 3
scripts: pretag.sh (which readies the branch for tagging), tag.sh
which does a simple svn cp and then posttag.sh which updates
for the next round. Once the tag is created, we can use the
existing release.sh to roll the tarballs and then your push.sh
to move them to to dist.

Having a set of small, single-purpose scripts that we chain
together is nicer than a large script that tries to do it all,
IMO.

> On Feb 20, 2018, at 9:35 AM, Daniel Ruggeri  wrote:
> 
> 
>> -Original Message-
>> From: Jim Jagielski [mailto:j...@jagunet.com]
>> Sent: Monday, February 19, 2018 9:47 AM
>> To: dev@httpd.apache.org
>> Subject: Re: svn commit: r1824751 [1/2] - in /httpd/httpd/branches/2.4.x:
> ./
>> docs/manual/ docs/manual/mod/ include/
>> 
>> 
>> 
>>> On Feb 19, 2018, at 10:33 AM, Ruediger Pluem 
>> wrote:
 
>>> 
>>> I guess you used your release procedures / scripts for rolling the
> release. So
>> some comments :-)
>>> 
>> 
>> Where are these? I don't see them in
>> 
>>https://svn.apache.org/repos/asf/httpd/site/trunk/tools
>> 
>> 
> 
> Sorry about that - for some reason I hadn't yet pushed them upstream. Just
> pushed in r1824887 (tag.sh and push.sh).
> 
> -- 
> Daniel Ruggeri
> 

Re: svn commit: r1824887 - in /httpd/site/trunk/tools: push.sh tag.sh

[Yann Ylavic]

On Tue, Feb 20, 2018 at 3:33 PM,   wrote:
> Author: druggeri
> Date: Tue Feb 20 14:33:38 2018
> New Revision: 1824887
>
> URL: http://svn.apache.org/viewvc?rev=1824887=rev
> Log:
> Add some additional convenience tooling
>
> Added:
[]
> httpd/site/trunk/tools/tag.sh   (with props)
[]
>
> Added: httpd/site/trunk/tools/tag.sh
> URL: 
> http://svn.apache.org/viewvc/httpd/site/trunk/tools/tag.sh?rev=1824887=auto
> ==
> --- httpd/site/trunk/tools/tag.sh (added)
> +++ httpd/site/trunk/tools/tag.sh Tue Feb 20 14:33:38 2018
[]
> +
> +cd "$src_dir"
> +#Set AP_SERVER_DEVBUILD_BOOLEAN to 0 in include/ap_release.h.
> +perl -pi -e 's/(#define\s+AP_SERVER_DEVBUILD_BOOLEAN\s+)\d/${1}0/g' 
> include/ap_release.h
> +svn commit -m "Get ready to tag httpd $version"
> +
> +
> +#Create an official X.Y.Z tag based on the candidate tree.
> +svn copy "$src_dir" "$tags_dir/$version"

Could we use remote urls here to avoid local modifications mixture?
Eg.: svn copy ^/httpd/httpd/branches/$branch ^/httpd/httpd/tags/$version
The tag shouldn't (possibly) include anything not in the branch.

Regards,
Yann.

RE: svn commit: r1824751 [1/2] - in /httpd/httpd/branches/2.4.x: ./ docs/manual/ docs/manual/mod/ include/

[Daniel Ruggeri]

> -Original Message-
> From: Jim Jagielski [mailto:j...@jagunet.com]
> Sent: Monday, February 19, 2018 9:47 AM
> To: dev@httpd.apache.org
> Subject: Re: svn commit: r1824751 [1/2] - in /httpd/httpd/branches/2.4.x:
./
> docs/manual/ docs/manual/mod/ include/
> 
> 
> 
> > On Feb 19, 2018, at 10:33 AM, Ruediger Pluem 
> wrote:
> >>
> >
> > I guess you used your release procedures / scripts for rolling the
release. So
> some comments :-)
> >
> 
> Where are these? I don't see them in
> 
> https://svn.apache.org/repos/asf/httpd/site/trunk/tools
> 
> 

Sorry about that - for some reason I hadn't yet pushed them upstream. Just
pushed in r1824887 (tag.sh and push.sh).

-- 
Daniel Ruggeri

RE: svn commit: r1824751 [1/2] - in /httpd/httpd/branches/2.4.x: ./ docs/manual/ docs/manual/mod/ include/

[Daniel Ruggeri]

> -Original Message-
> From: Ruediger Pluem [mailto:rpl...@apache.org]
> Sent: Monday, February 19, 2018 9:34 AM
> To: dev@httpd.apache.org
> Subject: Re: svn commit: r1824751 [1/2] - in /httpd/httpd/branches/2.4.x: ./
> docs/manual/ docs/manual/mod/ include/
> 
> 
> 
> On 02/19/2018 03:18 PM, drugg...@apache.org wrote:
> > Author: druggeri
> > Date: Mon Feb 19 14:18:51 2018
> > New Revision: 1824751
> >
> > URL: http://svn.apache.org/viewvc?rev=1824751=rev
> > Log:
> > Post 2.4.30 tag updates
> >
> > Modified:
> > httpd/httpd/branches/2.4.x/CHANGES
> > httpd/httpd/branches/2.4.x/STATUS
> > httpd/httpd/branches/2.4.x/docs/manual/convenience.map
> > httpd/httpd/branches/2.4.x/docs/manual/mod/directives.html.de
> > httpd/httpd/branches/2.4.x/docs/manual/mod/directives.html.en
> > httpd/httpd/branches/2.4.x/docs/manual/mod/directives.html.es
> > httpd/httpd/branches/2.4.x/docs/manual/mod/directives.html.ja.utf8
> > httpd/httpd/branches/2.4.x/docs/manual/mod/directives.html.ko.euc-
> kr
> > httpd/httpd/branches/2.4.x/docs/manual/mod/directives.html.tr.utf8
> > httpd/httpd/branches/2.4.x/docs/manual/mod/directives.html.zh-
> cn.utf8
> > httpd/httpd/branches/2.4.x/docs/manual/mod/index.html.de
> > httpd/httpd/branches/2.4.x/docs/manual/mod/index.html.en
> > httpd/httpd/branches/2.4.x/docs/manual/mod/index.html.es
> > httpd/httpd/branches/2.4.x/docs/manual/mod/index.html.ja.utf8
> > httpd/httpd/branches/2.4.x/docs/manual/mod/index.html.ko.euc-kr
> > httpd/httpd/branches/2.4.x/docs/manual/mod/index.html.tr.utf8
> > httpd/httpd/branches/2.4.x/docs/manual/mod/index.html.zh-cn.utf8
> > httpd/httpd/branches/2.4.x/docs/manual/mod/mod_remoteip.html.en
> > httpd/httpd/branches/2.4.x/docs/manual/mod/mod_ssl.html.en
> > httpd/httpd/branches/2.4.x/docs/manual/mod/overrides.html.en
> > httpd/httpd/branches/2.4.x/docs/manual/mod/quickreference.html.de
> > httpd/httpd/branches/2.4.x/docs/manual/mod/quickreference.html.en
> > httpd/httpd/branches/2.4.x/docs/manual/mod/quickreference.html.es
> >
> httpd/httpd/branches/2.4.x/docs/manual/mod/quickreference.html.ja.utf8
> >
> httpd/httpd/branches/2.4.x/docs/manual/mod/quickreference.html.ko.euc
> -kr
> >
> httpd/httpd/branches/2.4.x/docs/manual/mod/quickreference.html.tr.utf8
> > httpd/httpd/branches/2.4.x/docs/manual/mod/quickreference.html.zh-
> cn.utf8
> > httpd/httpd/branches/2.4.x/docs/manual/sections.html.tr.utf8
> > httpd/httpd/branches/2.4.x/docs/manual/sitemap.html.de
> > httpd/httpd/branches/2.4.x/docs/manual/sitemap.html.en
> > httpd/httpd/branches/2.4.x/docs/manual/sitemap.html.es
> > httpd/httpd/branches/2.4.x/docs/manual/sitemap.html.ja.utf8
> > httpd/httpd/branches/2.4.x/docs/manual/sitemap.html.tr.utf8
> > httpd/httpd/branches/2.4.x/docs/manual/sitemap.html.zh-cn.utf8
> > httpd/httpd/branches/2.4.x/include/ap_release.h
> 
> I guess you used your release procedures / scripts for rolling the release. So
> some comments :-)

Correct! Thanks for these!


> 
> I miss the increase of the httpd.patch entity in
> docs/manual/style/version.ent.

Good find. Corrected in the script.

> 
> >
> > Modified: httpd/httpd/branches/2.4.x/CHANGES
> > URL:
> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/CHANGES?rev=1
> 824751=1824750=1824751=diff
> >
> ==
> 
> > --- httpd/httpd/branches/2.4.x/CHANGES [utf-8] (original)
> > +++ httpd/httpd/branches/2.4.x/CHANGES [utf-8] Mon Feb 19 14:18:51
> 2018
> > @@ -1,6 +1,8 @@
> >   -*- coding: utf-8 
> > -*-
> >  Changes with Apache 2.4.30
> >
> > +Changes with Apache 2.4.30
> > +
> 
> I guess you want to add a 'Changes with Apache 2.4.31'
> 

Right - easily fixable error. Thanks for the catch.


> 
> >*) mod_proxy: Provide an RFC1035 compliant version of the hostname in
> the
> >   proxy_worker_shared structure. PR62085 [Graham Leggett]
> >
> >
> > Modified: httpd/httpd/branches/2.4.x/STATUS
> > URL:
> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=182
> 4751=1824750=1824751=diff
> >
> ==
> 
> > --- httpd/httpd/branches/2.4.x/STATUS (original)
> > +++ httpd/httpd/branches/2.4.x/STATUS Mon Feb 19 14:18:51 2018
> > @@ -29,7 +29,7 @@ Release history:
> >  [NOTE that x.{odd}.z versions are strictly Alpha/Beta releases,
> >while x.{even}.z versions are Stable/GA releases.]
> >
> > -2.4.30  : In development. Jim proposes a T Feb. 19, 2018.
> > +-8s2.4.30  : In development. Jim proposes a T Feb. 19, 2018.
> 
> I guess you want to mark 2.4.30 as tagged.

Correct - also an easy fix.

> 
> >  2.4.29  : Tagged on October 17, 2017. Released on October 23, 2017.
> >  2.4.28  : Tagged on September 25, 2017. Released on October 5, 2017.
> >  2.4.27 

Save the date: ApacheCon North America, September 24-27 in Montréal

[Rich Bowen]

Dear Apache Enthusiast,

(You’re receiving this message because you’re subscribed to a user@ or 
dev@ list of one or more Apache Software Foundation projects.)


We’re pleased to announce the upcoming ApacheCon [1] in Montréal, 
September 24-27. This event is all about you — the Apache project community.


We’ll have four tracks of technical content this time, as well as lots 
of opportunities to connect with your project community, hack on the 
code, and learn about other related (and unrelated!) projects across the 
foundation.


The Call For Papers (CFP) [2] and registration are now open. Register 
early to take advantage of the early bird prices and secure your place 
at the event hotel.


Important dates
March 30: CFP closes
April 20: CFP notifications sent
	August 24: Hotel room block closes (please do not wait until the last 
minute)


Follow @ApacheCon on Twitter to be the first to hear announcements about 
keynotes, the schedule, evening events, and everything you can expect to 
see at the event.


See you in Montréal!

Sincerely, Rich Bowen, V.P. Events,
on behalf of the entire ApacheCon team

[1] http://www.apachecon.com/acna18
[2] https://cfp.apachecon.com/conference.html?apachecon-north-america-2018

Save the date: ApacheCon North America, September 24-27 in Montréal

[Rich Bowen]

Dear Apache Enthusiast,

(You’re receiving this message because you’re subscribed to a user@ or 
dev@ list of one or more Apache Software Foundation projects.)


We’re pleased to announce the upcoming ApacheCon [1] in Montréal, 
September 24-27. This event is all about you — the Apache project community.


We’ll have four tracks of technical content this time, as well as lots 
of opportunities to connect with your project community, hack on the 
code, and learn about other related (and unrelated!) projects across the 
foundation.


The Call For Papers (CFP) [2] and registration are now open. Register 
early to take advantage of the early bird prices and secure your place 
at the event hotel.


Important dates
March 30: CFP closes
April 20: CFP notifications sent
	August 24: Hotel room block closes (please do not wait until the last 
minute)


Follow @ApacheCon on Twitter to be the first to hear announcements about 
keynotes, the schedule, evening events, and everything you can expect to 
see at the event.


See you in Montréal!

Sincerely, Rich Bowen, V.P. Events,
on behalf of the entire ApacheCon team

[1] http://www.apachecon.com/acna18
[2] https://cfp.apachecon.com/conference.html?apachecon-north-america-2018

Re: [VOTE] Release httpd-2.4.30

[Jim Jagielski]

If we could see the tooling it might be easier to vet it.

> On Feb 20, 2018, at 8:39 AM, drugg...@primary.net wrote:
> 
>> -Original Message-
>> From: Jim Jagielski [mailto:j...@jagunet.com]
>> Sent: Tuesday, February 20, 2018 6:10 AM
>> To: dev@httpd.apache.org
>> Subject: Re: [VOTE] Release httpd-2.4.30
>> 
>> Another thing that helps is providing some heads-up
>> that a T will actually be happening... Yeah, you
>> had noted the you were going to T on Monday
>> (in the "T of 2.4.30 Proposal" thread) but sending
>> out a quick "I plan on doing this in X hours" notice
>> allows for some possible last-minute items to pop
>> up.
>> 
>> Just a suggestion.
> 
> Sure, I can do that.
> 
> 
>> 
>>> On Feb 19, 2018, at 9:44 PM, Jim Jagielski >> > wrote:
>>> 
>>> I would suggest using the scripts from
>>> 
>>>https://svn.apache.org/repos/asf/httpd/site/trunk/tools 
>>> 
>>> 
>>> for as much of the work as possible since they have been used
>>> and vetted for several years.
> 
> Indeed, I did for everything except the tagging (which is why I created a 
> script to do it). I also created one to push to dev/release dist repos for 
> convenience. As mentioned, the goal is to automate the process as much as 
> possible so with the gap in existing tooling, I went ahead and filled it. I 
> guess I just misinterpreted the instructions and didn’t think to review SVN 
> history of the previous releases as Joe mentioned.
> 
> Aside from this omission, are we otherwise in good shape?
> 
> 
>>> 
 On Feb 19, 2018, at 7:28 PM, drugg...@primary.net wrote:
 
 Ah, I see. I created a script that does the tagging based on the directions
>> here.
 http://httpd.apache.org/dev/release.html
 
 It was unclear in those instructions that one should commit the change to
>> AP_SERVER_DEVBUILD_BOOLEAN.
 
 Instead I did the following:
 ...
 #Set AP_SERVER_DEVBUILD_BOOLEAN to 0 in include/ap_release.h.
 perl -pi -e 's/(#define\s+AP_SERVER_DEVBUILD_BOOLEAN\s+)\d/${1}0/g'
>> include/ap_release.h
 
 #Create an official X.Y.Z tag based on the candidate tree.
 svn copy "$src_dir" "$tags_dir/$version"
 
 #Revert the change to include/ap_release.h setting
>> AP_SERVER_DEVBUILD_BOOLEAN back to 1, and bump
>> AP_SERVER_PATCHLEVEL_NUMBER
 perl -pi -e '
 s/(#define\s+AP_SERVER_DEVBUILD_BOOLEAN\s+)\d/${1}1/g;
 
 if(/(#define\s+AP_SERVER_PATCHLEVEL_NUMBER\s+)(\d+)$/){
   $new = $2 + 1;
   $_ = "${1}${new}\n";
 }
 ' include/ap_release.h
 ...
 
 This begets a tarball that has the Boolean set to 0, but no
>> commit/revert/bump (instead just an apparent bump):
 
>> http://svn.apache.org/viewvc/httpd/httpd/tags/2.4.30/include/ap_release.
>> h?view=markup#l47
 
 It makes sense that the tag comes from a specific commit where the
>> variable was flipped...  Should I adjust the script and retry?
 
 --
 Daniel Ruggeri
 
 From: Jim Jagielski [mailto:j...@jagunet.com]
 Sent: Monday, February 19, 2018 9:46 AM
 To: dev@httpd.apache.org
 Subject: Re: [VOTE] Release httpd-2.4.30
 
 Hmmm... I'm not seeing the patch where
>> AP_SERVER_DEVBUILD_BOOLEAN
 in ap_release.h is set to 0
 
 How does your release process work? What we've always
 done is make the req changes to the branch and then copy
 from that branch to the tag. So the tag itself must refer to
 a specific SVN number on the http-2.4 branch but I'm
 not seeing where that is done.
 
 
 On Feb 19, 2018, at 9:54 AM, mailto:drugg...@primary.net wrote:
 
 Hi, all;
  Please find below the proposed release tarball and signatures:
 https://dist.apache.org/repos/dist/dev/httpd/
 
 I would like to call a VOTE over the next few days to release this 
 candidate
>> tarball as 2.4.30:
 
 [ ] +1: It’s not just good, it’s good enough!
 [ ] +0: Let’s have a talk…
 [ ] -1: There’s trouble in paradise. Here’s what’s wrong.
 --
 Daniel Ruggeri
 
 
> 
> -- 
> Daniel Ruggeri

Re: Test framework error on HEAD 2.4 (r1824869)

[Yann Ylavic]

Thanks Jim.

On Tue, Feb 20, 2018 at 2:52 PM, Jim Jagielski  wrote:
> Yep. All good now (r1824880)
>
>> On Feb 20, 2018, at 8:47 AM, Yann Ylavic  wrote:
>>
>> Should be OK now with the right merge, right?
>>
>> On Tue, Feb 20, 2018 at 2:25 PM, Jim Jagielski  wrote:
>>> Confirmed that w/ r1824874, where the Event MPM changes
>>> had been reverted, this no longer happens.
>>>
 On Feb 20, 2018, at 8:17 AM, Jim Jagielski  wrote:

 This is on macOS and using Event. Note that trunk
 does not have this issue:

 Test Summary Report
 ---
 t/apache/pr35292.t(Wstat: 0 Tests: 3 Failed: 1)
 Failed test:  2

>>>
>

Re: Test framework error on HEAD 2.4 (r1824869)

[Jim Jagielski]

Yep. All good now (r1824880)

> On Feb 20, 2018, at 8:47 AM, Yann Ylavic  wrote:
> 
> Should be OK now with the right merge, right?
> 
> On Tue, Feb 20, 2018 at 2:25 PM, Jim Jagielski  wrote:
>> Confirmed that w/ r1824874, where the Event MPM changes
>> had been reverted, this no longer happens.
>> 
>>> On Feb 20, 2018, at 8:17 AM, Jim Jagielski  wrote:
>>> 
>>> This is on macOS and using Event. Note that trunk
>>> does not have this issue:
>>> 
>>> Test Summary Report
>>> ---
>>> t/apache/pr35292.t(Wstat: 0 Tests: 3 Failed: 1)
>>> Failed test:  2
>>> 
>> 

Re: Test framework error on HEAD 2.4 (r1824869)

[Yann Ylavic]

Should be OK now with the right merge, right?

On Tue, Feb 20, 2018 at 2:25 PM, Jim Jagielski  wrote:
> Confirmed that w/ r1824874, where the Event MPM changes
> had been reverted, this no longer happens.
>
>> On Feb 20, 2018, at 8:17 AM, Jim Jagielski  wrote:
>>
>> This is on macOS and using Event. Note that trunk
>> does not have this issue:
>>
>> Test Summary Report
>> ---
>> t/apache/pr35292.t(Wstat: 0 Tests: 3 Failed: 1)
>>  Failed test:  2
>>
>

RE: [VOTE] Release httpd-2.4.30

[DRuggeri]

> -Original Message-
> From: Jim Jagielski [mailto:j...@jagunet.com]
> Sent: Tuesday, February 20, 2018 6:10 AM
> To: dev@httpd.apache.org
> Subject: Re: [VOTE] Release httpd-2.4.30
> 
> Another thing that helps is providing some heads-up
> that a T will actually be happening... Yeah, you
> had noted the you were going to T on Monday
> (in the "T of 2.4.30 Proposal" thread) but sending
> out a quick "I plan on doing this in X hours" notice
> allows for some possible last-minute items to pop
> up.
> 
> Just a suggestion.

Sure, I can do that.


> 
> > On Feb 19, 2018, at 9:44 PM, Jim Jagielski  wrote:
> >
> > I would suggest using the scripts from
> >
> > https://svn.apache.org/repos/asf/httpd/site/trunk/tools
> >
> > for as much of the work as possible since they have been used
> > and vetted for several years.

Indeed, I did for everything except the tagging (which is why I created a 
script to do it). I also created one to push to dev/release dist repos for 
convenience. As mentioned, the goal is to automate the process as much as 
possible so with the gap in existing tooling, I went ahead and filled it. I 
guess I just misinterpreted the instructions and didn’t think to review SVN 
history of the previous releases as Joe mentioned.

Aside from this omission, are we otherwise in good shape?


> >
> >> On Feb 19, 2018, at 7:28 PM, drugg...@primary.net wrote:
> >>
> >> Ah, I see. I created a script that does the tagging based on the directions
> here.
> >> http://httpd.apache.org/dev/release.html
> >>
> >> It was unclear in those instructions that one should commit the change to
> AP_SERVER_DEVBUILD_BOOLEAN.
> >>
> >> Instead I did the following:
> >> ...
> >> #Set AP_SERVER_DEVBUILD_BOOLEAN to 0 in include/ap_release.h.
> >> perl -pi -e 's/(#define\s+AP_SERVER_DEVBUILD_BOOLEAN\s+)\d/${1}0/g'
> include/ap_release.h
> >>
> >> #Create an official X.Y.Z tag based on the candidate tree.
> >> svn copy "$src_dir" "$tags_dir/$version"
> >>
> >> #Revert the change to include/ap_release.h setting
> AP_SERVER_DEVBUILD_BOOLEAN back to 1, and bump
> AP_SERVER_PATCHLEVEL_NUMBER
> >> perl -pi -e '
> >>  s/(#define\s+AP_SERVER_DEVBUILD_BOOLEAN\s+)\d/${1}1/g;
> >>
> >>  if(/(#define\s+AP_SERVER_PATCHLEVEL_NUMBER\s+)(\d+)$/){
> >>$new = $2 + 1;
> >>$_ = "${1}${new}\n";
> >>  }
> >>  ' include/ap_release.h
> >> ...
> >>
> >> This begets a tarball that has the Boolean set to 0, but no
> commit/revert/bump (instead just an apparent bump):
> >>
> http://svn.apache.org/viewvc/httpd/httpd/tags/2.4.30/include/ap_release.
> h?view=markup#l47
> >>
> >> It makes sense that the tag comes from a specific commit where the
> variable was flipped...  Should I adjust the script and retry?
> >>
> >> --
> >> Daniel Ruggeri
> >>
> >> From: Jim Jagielski [mailto:j...@jagunet.com]
> >> Sent: Monday, February 19, 2018 9:46 AM
> >> To: dev@httpd.apache.org
> >> Subject: Re: [VOTE] Release httpd-2.4.30
> >>
> >> Hmmm... I'm not seeing the patch where
> AP_SERVER_DEVBUILD_BOOLEAN
> >> in ap_release.h is set to 0
> >>
> >> How does your release process work? What we've always
> >> done is make the req changes to the branch and then copy
> >> from that branch to the tag. So the tag itself must refer to
> >> a specific SVN number on the http-2.4 branch but I'm
> >> not seeing where that is done.
> >>
> >>
> >> On Feb 19, 2018, at 9:54 AM, mailto:drugg...@primary.net wrote:
> >>
> >> Hi, all;
> >>   Please find below the proposed release tarball and signatures:
> >> https://dist.apache.org/repos/dist/dev/httpd/
> >>
> >> I would like to call a VOTE over the next few days to release this 
> >> candidate
> tarball as 2.4.30:
> >>
> >> [ ] +1: It’s not just good, it’s good enough!
> >> [ ] +0: Let’s have a talk…
> >> [ ] -1: There’s trouble in paradise. Here’s what’s wrong.
> >> --
> >> Daniel Ruggeri
> >>
> >>

-- 
Daniel Ruggeri

Re: Test framework error on HEAD 2.4 (r1824869)

[Jim Jagielski]

Confirmed that w/ r1824874, where the Event MPM changes
had been reverted, this no longer happens.

> On Feb 20, 2018, at 8:17 AM, Jim Jagielski  wrote:
> 
> This is on macOS and using Event. Note that trunk
> does not have this issue:
> 
> Test Summary Report
> ---
> t/apache/pr35292.t(Wstat: 0 Tests: 3 Failed: 1)
>  Failed test:  2
> 

Test framework error on HEAD 2.4 (r1824869)

[Jim Jagielski]

This is on macOS and using Event. Note that trunk
does not have this issue:

Test Summary Report
---
t/apache/pr35292.t(Wstat: 0 Tests: 3 Failed: 1)
  Failed test:  2

Re: svn commit: r1824868 - in /httpd/httpd/branches/2.4.x: ./ CHANGES include/ap_mmn.h include/httpd.h server/mpm/event/event.c

[Yann Ylavic]

On Tue, Feb 20, 2018 at 1:56 PM,   wrote:
> Author: ylavic
> Date: Tue Feb 20 12:56:16 2018
> New Revision: 1824868
>
> URL: http://svn.apache.org/viewvc?rev=1824868=rev
> Log:
> Merge r1823047, r1824454, r1824463, r1824464, r1824497, r1824862 from trunk:
[]
>
> MMN bump for CONN_STATE_NUM, plus don't consider CONN_STATE_LINGER_* as valid
> states returned process_connection (never have been).

Argh, sorry, this change is not valid, will revert :/
Didn't mean to mix MMN and functional change...

Re: mod_md in docu no valid Certificate Agreement

[Stefan Eissing]

elukey did fix the agreements in trunk. Now merged into 2.4.x in r1824871. 
Thanks for checking.

> Am 20.02.2018 um 13:42 schrieb Steffen :
> 
> 
> In the mod_md 2.4 (not in trunk) documentation 
> https://httpd.apache.org/docs/2.4/mod/mod_md.html
> 
> 
> I see three times:
> 
> MDCertificateAgreement 
> https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf
> 
> This errors if not an existing account.
> 
> It should be now (should be nice we have it in 2.4.31) :
> 
> MDCertificateAgreement 
> https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf
> 
> 
> As long as the CA reports that the account has an agreement in mod_md, no 
> further checking is done. Existing accounts need no changes with
> this new agreement.
> 
> 
> I can see that the Wiki docu is newer:  https://github.com/icing/mod_md/wiki.
> 
> 
> Cannot check if the rest of mod_md docu is up to date and in line with trunk  
> ?
> 
> 
> 
> 
> 
> 
> 

mod_md in docu no valid Certificate Agreement

[Steffen]

In the mod_md 2.4 (not in trunk) documentation 
https://httpd.apache.org/docs/2.4/mod/mod_md.html



I see three times:

MDCertificateAgreement 
https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf


This errors if not an existing account.

It should be now (should be nice we have it in 2.4.31) :

MDCertificateAgreement 
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf



As long as the CA reports that the account has an agreement in mod_md, 
no further checking is done. Existing accounts need no changes with

this new agreement.


I can see that the Wiki docu is newer:  
https://github.com/icing/mod_md/wiki.



Cannot check if the rest of mod_md docu is up to date and in line with 
trunk  ?

Re: [VOTE] Release httpd-2.4.30

[Jim Jagielski]

Another thing that helps is providing some heads-up
that a T will actually be happening... Yeah, you
had noted the you were going to T on Monday
(in the "T of 2.4.30 Proposal" thread) but sending
out a quick "I plan on doing this in X hours" notice
allows for some possible last-minute items to pop
up.

Just a suggestion.

> On Feb 19, 2018, at 9:44 PM, Jim Jagielski  wrote:
> 
> I would suggest using the scripts from
> 
> https://svn.apache.org/repos/asf/httpd/site/trunk/tools
> 
> for as much of the work as possible since they have been used
> and vetted for several years.
> 
>> On Feb 19, 2018, at 7:28 PM, drugg...@primary.net wrote:
>> 
>> Ah, I see. I created a script that does the tagging based on the directions 
>> here.
>> http://httpd.apache.org/dev/release.html
>> 
>> It was unclear in those instructions that one should commit the change to 
>> AP_SERVER_DEVBUILD_BOOLEAN.
>> 
>> Instead I did the following:
>> ...
>> #Set AP_SERVER_DEVBUILD_BOOLEAN to 0 in include/ap_release.h.
>> perl -pi -e 's/(#define\s+AP_SERVER_DEVBUILD_BOOLEAN\s+)\d/${1}0/g' 
>> include/ap_release.h
>> 
>> #Create an official X.Y.Z tag based on the candidate tree.
>> svn copy "$src_dir" "$tags_dir/$version"
>> 
>> #Revert the change to include/ap_release.h setting 
>> AP_SERVER_DEVBUILD_BOOLEAN back to 1, and bump AP_SERVER_PATCHLEVEL_NUMBER
>> perl -pi -e '
>>  s/(#define\s+AP_SERVER_DEVBUILD_BOOLEAN\s+)\d/${1}1/g;
>> 
>>  if(/(#define\s+AP_SERVER_PATCHLEVEL_NUMBER\s+)(\d+)$/){
>>$new = $2 + 1;
>>$_ = "${1}${new}\n";
>>  }
>>  ' include/ap_release.h
>> ...
>> 
>> This begets a tarball that has the Boolean set to 0, but no 
>> commit/revert/bump (instead just an apparent bump):
>> http://svn.apache.org/viewvc/httpd/httpd/tags/2.4.30/include/ap_release.h?view=markup#l47
>> 
>> It makes sense that the tag comes from a specific commit where the variable 
>> was flipped...  Should I adjust the script and retry?
>> 
>> -- 
>> Daniel Ruggeri
>> 
>> From: Jim Jagielski [mailto:j...@jagunet.com] 
>> Sent: Monday, February 19, 2018 9:46 AM
>> To: dev@httpd.apache.org
>> Subject: Re: [VOTE] Release httpd-2.4.30
>> 
>> Hmmm... I'm not seeing the patch where AP_SERVER_DEVBUILD_BOOLEAN
>> in ap_release.h is set to 0
>> 
>> How does your release process work? What we've always
>> done is make the req changes to the branch and then copy
>> from that branch to the tag. So the tag itself must refer to
>> a specific SVN number on the http-2.4 branch but I'm
>> not seeing where that is done.
>> 
>> 
>> On Feb 19, 2018, at 9:54 AM, mailto:drugg...@primary.net wrote:
>> 
>> Hi, all;
>>   Please find below the proposed release tarball and signatures:
>> https://dist.apache.org/repos/dist/dev/httpd/
>> 
>> I would like to call a VOTE over the next few days to release this candidate 
>> tarball as 2.4.30:
>> 
>> [ ] +1: It’s not just good, it’s good enough!
>> [ ] +0: Let’s have a talk…
>> [ ] -1: There’s trouble in paradise. Here’s what’s wrong.
>> -- 
>> Daniel Ruggeri
>> 
>> 
> 

Re: [VOTE] Release httpd-2.4.30

[Jim Jagielski]

-1: I think with the release process hiccups and the Win issues
noted in the "Current branche 2.4.30-dev issues" thread,
we will need a 2.4.31. Additionally, there are some
backports in STATUS that could also be folded in.

> On Feb 19, 2018, at 9:54 AM, drugg...@primary.net wrote:
> 
> Hi, all;
>Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
>  
> I would like to call a VOTE over the next few days to release this candidate 
> tarball as 2.4.30:
>  
> [ ] +1: It’s not just good, it’s good enough!
> [ ] +0: Let’s have a talk…
> [ ] -1: There’s trouble in paradise. Here’s what’s wrong.
> -- 
> Daniel Ruggeri

Re: Current branche 2.4.30-dev issues

[Steffen]

Re: Current branche 2.4.30-dev issues

[Jan Ehrhardt]

Steffen in gmane.comp.apache.devel (Mon, 19 Feb 2018 12:38:27 +0100):
>Added  mod_proxy_uwsgi to installwinconf.awk and BasAddr.ref in trunk 
>and branches.

Apache.dsw needs an addition too:

###

Project: "mod_proxy_uwsgi"=.\modules\proxy\mod_proxy_uwsgi.dsp - Package
Owner=<4>

Package=<5>
{{{
}}}

Package=<4>
{{{
Begin Project Dependency
Project_Dep_Name libapr
End Project Dependency
Begin Project Dependency
Project_Dep_Name libaprutil
End Project Dependency
Begin Project Dependency
Project_Dep_Name libhttpd
End Project Dependency
Begin Project Dependency
Project_Dep_Name mod_proxy
End Project Dependency
}}}

###
-- 
Jan

Re: svn commit: r1824592 - /httpd/httpd/branches/2.4.x/STATUS

[Joe Orton]

On Mon, Feb 19, 2018 at 08:38:05PM +0100, Ruediger Pluem wrote:
> On 02/19/2018 07:50 PM, Joe Orton wrote:
> > On Sat, Feb 17, 2018 at 02:06:20PM -, minf...@apache.org wrote:
> >> Author: minfrin
> >> Date: Sat Feb 17 14:06:20 2018
> >> New Revision: 1824592
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1824592=rev
> >> Log:
> >> Update proposal with fix for rpluem/jorton.
> > 
> > Extending dav_resource still breaks binary backards compat with all(?) 
> > consumers of this API, or am I missing something here?
> 
> I don't think so. Modules that just work with pointers to structs created by 
> mod_dav shouldn't
> have any issues, but see below.

Looking again, I think the way the mod_dav API is designed does make it 
necessary for consumers of the API to allocate dav_resource structures.  
There are a number of hooks like ->get_resource():

dav_error * (*get_resource)(
request_rec *r,
const char *root_dir,
const char *label,
int use_checked_in,
dav_resource **resource
);

... which are implemented in repos providers which must allocate that 
*resource, and hence changing sizeof(dav_resource) will break binary BC, 
even if the structure was not embedded anywhere.

> > Look at what mod_dav_svn does with the struct for an example: 
> > https://svn.apache.org/viewvc/subversion/trunk/subversion/mod_dav_svn/repos.c?view=markup#l80
> 
> I guess this gets us back to this _copy / _sizeof discussion we had in 
> another thread recently.
> Creating structures / allocating memory for them in modules is IMHO a recipe 
> to fail with our current
> backporting policy as we allow to extend structures at the end.

Yup.

In this case would moving ->acls and ->ctx to a pool note of the ->pool 
field (actually is ->ctx actually used??) might work to preserve BC?

Regards, Joe