Re: 2.6/3.0

[Daniel Ruggeri]

On 12/9/2016 8:32 AM, Jim Jagielski wrote:
> Instead, maybe we could backport all that stuff to 2.4, in a backwards
> compatible fashion. That is, basically backport trunk to 2.4. This
> would give us more runway to work on httpd-nextgen.
>
> Thoughts?

Considering a lot of the changes in trunk, I'm not entirely sure it can
be backported without creating some code maintenance challenges...

I agree about the concern w/ branching so I guess it's really a matter
of weighing the benefits - are there *enough* features to be worthy of a
release, have we reached API stability to make it worth it and do we
lose anything in our "sandbox" by doing this? Pressed for a response,
I'd lean towards probably not but it's not a terribly strong opinion.


It's also not unprecedented to have three major versions in play, too.
It's been announced that 2.2 is on the "EOL" track with most folks
interested in maintaining that branch in the 12 to 18 month range (June
- Dec 2017ish). So, that said, it wouldn't be a super long time we
maintain three branches... a year-ish from now.

-- 
Daniel Ruggeri

Re: 2.6/3.0

[William A Rowe Jr]

On Fri, Dec 9, 2016 at 8:32 AM, Jim Jagielski  wrote:

> It may be weird talking about httpd 2.6/3.0 when we are stuck
> in a holding pattern for 2.4.24, but actually it's not a bad
> idea.
>
> Right now, there are quite a few improvements in trunk that
> should *really* be in a releasable version... Now we have some
> options on how to proceed, but my modus operandi has been to
> "push" as much trunk goodness back to 2.4 as possible, leaving
> trunk still a nice sandbox for development on how we really want
> to architecture the next gen (slave connections, etc...). So
> as much as I think we should continue that, I also think it's
> a disservice to keep the async, et.al. improvements in trunk,
> well, in trunk. So we could fork 2.6 from trunk and work on
> releasing 2.6. Assuming that we do so in a timely fashion, that
> would mean we would have 3 versions out: 2.2, 2.4, and 2.6.
> Considering that 2.4 is finally showing some traction, I wonder
> if that's the right move.
>

Well, that isn't how we work, we don't fork 2.6 before 2.5.whatnot.

We release 2.5.0-alpha (or -beta). Unless you want to redesign
the process and open that hard-won consensus all over again.
Then another -alpha/-beta, and so on, until we have consensus
to tag trunk as the 2.6.0/3.0.0 release. Then we take a deep
breath and fork 2.6.x/3.0.x branch from trunk.

This keeps 2.5 as close to the bleeding edge as possible during
the next release process, with major API changes and broken
binary compatibility between the individual alpha/beta samples,
so that others in our ecosystem may adapt their modules
throughout the process, and are (one hopes) ready for the
2.6.0/3.0.0 release.

You and I (and others, I suspect) agree there is a lot of trunk
goodness to release soon. Other things that would likely happen
during the 2.5.x phases are a reworking/restructuring of utility
vs server facilities (something which is a complete mess at this
moment), collapsing _ex() functions into their historic function
names, etc. Restoring the ability to load modules out of order
after the chaos of poorly thought out new 'hub-and-spoke'
modules. And there are other discussions afoot around the
PMC about major API changes that will break some developer
assumptions, and I believe will cause us to take this to 3.0.0,
not some minor revision bump.


> Instead, maybe we could backport all that stuff to 2.4, in a backwards
> compatible fashion. That is, basically backport trunk to 2.4. This
> would give us more runway to work on httpd-nextgen.
>

That is very unrealistic, given that the trunk patches have broken
ABI more than once a month for four years. Adapting such patches
would lead to many more inane forks like the HttpProtocol Strict
backport effort.

The other 'instead' is that we could throw away trunk, and branch
a new trunk from 2.4.x branch, if we are not comfortable releasing
the contents of trunk as an alpha or beta release. I hope that's not
the case.

Re: PCRE 10 and puzzling edge cases

[William A Rowe Jr]

On Fri, Dec 9, 2016 at 8:05 AM, Petr Pisar  wrote:

> On Thu, Dec 08, 2016 at 11:09:42AM -0600, William A Rowe Jr wrote:
> > I've beaten my head against this wall for a bit longer, and came up with
> > several places where pcre2 changed return types for void *what query
> > interogations (especially from int to uint32, badness on x86_64-linux).
> >
> > The attached patch picks up these bad void * type assignments. Still
> > no tremendous improvement, missing something blatantly obvious,
> > I expect.
> >
> After few hours of getting httpd sources and tests and hacking them to
> actually obtain a pass, I applied your patch and looked what's wrong with
> your
> PCRE2 code.
>

Thanks again, if there is anything that we didn't document well about
getting
the tests to run, we would like to fix that and make it easier for
developers
to cobble together their own test environment. We certainly don't want it
to take hours for an experienced newcomer to get from point a to point b.

Happy to improve this based on your observations.

The t/apache/expr.t failed because the pcre2_match() alwayes returned -51
> that means PCRE2_ERROR_NULL. The reason is you used the old PCRE
> optimization
> path and called pcre2_match_data_create(nmatch, NULL) only if nmatch was
> positive. As a result, pcre2_match_data_create() was never called, so you
> passed NULL matchdata to pcre2_match(), hence the failure.
>

Yup, that was a bad assumption on my part, reading pcre2api in parallel
with pcreapi.


> The tests still do not pass, but that's probably another (PCRE2) problem.
> I hope I helped you at lest somehow.
>

I do have it working, now committed. Failing tests are likely some missing
cpan modules in your setup still, or perhaps some tests that are making
bogus assumptions about the supported dependency libraries. Thanks for
the pointer, we seem to have succeeded!

Re: PCRE 10 and puzzling edge cases

[William A Rowe Jr]

On Dec 9, 2016 8:06 AM, "Petr Pisar"  wrote:

On Thu, Dec 08, 2016 at 11:09:42AM -0600, William A Rowe Jr wrote:
> I've beaten my head against this wall for a bit longer, and came up with
> several places where pcre2 changed return types for void *what query
> interogations (especially from int to uint32, badness on x86_64-linux).
>
> The attached patch picks up these bad void * type assignments. Still
> no tremendous improvement, missing something blatantly obvious,
> I expect.
>
After few hours of getting httpd sources and tests and hacking them to
actually obtain a pass, I applied your patch and looked what's wrong with
your
PCRE2 code.

The t/apache/expr.t failed because the pcre2_match() alwayes returned -51
that means PCRE2_ERROR_NULL. The reason is you used the old PCRE
optimization
path and called pcre2_match_data_create(nmatch, NULL) only if nmatch was
positive. As a result, pcre2_match_data_create() was never called, so you
passed NULL matchdata to pcre2_match(), hence the failure.

See the attached fix.

The tests still do not pass, but that's probably another (PCRE2) problem.
I hope I helped you at lest somehow


That's a huge help, thanks Petr.

I'm also curious along that path if adding PCRE2 (or PCRE) study pattern
would also be helpful. Something to experiment with once both code paths
are working.

Cheers,

Bill

2.6/3.0

[Jim Jagielski]

It may be weird talking about httpd 2.6/3.0 when we are stuck
in a holding pattern for 2.4.24, but actually it's not a bad
idea.

Right now, there are quite a few improvements in trunk that
should *really* be in a releasable version... Now we have some
options on how to proceed, but my modus operandi has been to
"push" as much trunk goodness back to 2.4 as possible, leaving
trunk still a nice sandbox for development on how we really want
to architecture the next gen (slave connections, etc...). So
as much as I think we should continue that, I also think it's
a disservice to keep the async, et.al. improvements in trunk,
well, in trunk. So we could fork 2.6 from trunk and work on
releasing 2.6. Assuming that we do so in a timely fashion, that
would mean we would have 3 versions out: 2.2, 2.4, and 2.6.
Considering that 2.4 is finally showing some traction, I wonder
if that's the right move.

Instead, maybe we could backport all that stuff to 2.4, in a backwards
compatible fashion. That is, basically backport trunk to 2.4. This
would give us more runway to work on httpd-nextgen.

Thoughts?

Re: T of 2.4.24

[Jim Jagielski]

> On Dec 9, 2016, at 12:20 AM, William A Rowe Jr  wrote:
> 
> On Thu, Dec 8, 2016 at 12:16 PM, William A Rowe Jr  
> wrote:
> 
> @VP Legal, is this worth an escalation? You didn't see fit to respond today,
> but I think this falls under the purview of your committee, w.r.t. unapproved
> release artifacts living at www.apache.org/dist/. Did you have any thoughts
> or opinions one way or another?

How is this different from, say, the win32 src zips or the
complimentary binary builds?

Re: PCRE 10 and puzzling edge cases

[Petr Pisar]

On Thu, Dec 08, 2016 at 11:09:42AM -0600, William A Rowe Jr wrote:
> I've beaten my head against this wall for a bit longer, and came up with
> several places where pcre2 changed return types for void *what query
> interogations (especially from int to uint32, badness on x86_64-linux).
> 
> The attached patch picks up these bad void * type assignments. Still
> no tremendous improvement, missing something blatantly obvious,
> I expect.
> 
After few hours of getting httpd sources and tests and hacking them to
actually obtain a pass, I applied your patch and looked what's wrong with your
PCRE2 code.

The t/apache/expr.t failed because the pcre2_match() alwayes returned -51
that means PCRE2_ERROR_NULL. The reason is you used the old PCRE optimization
path and called pcre2_match_data_create(nmatch, NULL) only if nmatch was
positive. As a result, pcre2_match_data_create() was never called, so you
passed NULL matchdata to pcre2_match(), hence the failure.

See the attached fix.

The tests still do not pass, but that's probably another (PCRE2) problem.
I hope I helped you at lest somehow.

-- Petr
From 5e28aa58b19fdbfe485f50668c3176fe23e25609 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Fri, 9 Dec 2016 14:59:57 +0100
Subject: [PATCH] Fix never match
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

PCRE2 always requires pcre2_match_data_create(). Otherwise
pcre2_match() returns PCRE2_ERROR_NULL.

Signed-off-by: Petr Písař 
---
 server/util_pcre.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/server/util_pcre.c b/server/util_pcre.c
index 845dd33..0c435ff 100644
--- a/server/util_pcre.c
+++ b/server/util_pcre.c
@@ -248,13 +248,13 @@ AP_DECLARE(int) ap_regexec_len(const ap_regex_t *preg, 
const char *buff,
 
 ((ap_regex_t *)preg)->re_erroffset = (apr_size_t)(-1);/* Only has 
meaning after compile */
 
-if (nmatch > 0) {
 #ifdef HAVE_PCRE2
-matchdata = pcre2_match_data_create(nmatch, NULL);
-if (matchdata == NULL)
-return AP_REG_ESPACE;
-ovector = pcre2_get_ovector_pointer(matchdata);
+matchdata = pcre2_match_data_create(nmatch, NULL);
+if (matchdata == NULL)
+return AP_REG_ESPACE;
+ovector = pcre2_get_ovector_pointer(matchdata);
 #else
+if (nmatch > 0) {
 if (nmatch <= POSIX_MALLOC_THRESHOLD) {
 ovector = &(small_ovector[0]);
 }
@@ -264,8 +264,8 @@ AP_DECLARE(int) ap_regexec_len(const ap_regex_t *preg, 
const char *buff,
 return AP_REG_ESPACE;
 allocated_ovector = 1;
 }
-#endif
 }
+#endif
 
 #ifdef HAVE_PCRE2
 rc = pcre2_match((const pcre2_code *)preg->re_pcre,
@@ -290,8 +290,7 @@ AP_DECLARE(int) ap_regexec_len(const ap_regex_t *preg, 
const char *buff,
 }
 
 #ifdef HAVE_PCRE2
-if (matchdata)
-pcre2_match_data_free(matchdata);
+pcre2_match_data_free(matchdata);
 #else
 if (allocated_ovector)
 free(ovector);
-- 
2.7.4



signature.asc
Description: PGP signature

Re: [RELEASE CANDIDATE] libapreq2-2.14 RC

[Steve Hay]

On 5 December 2016 at 16:14, Issac Goldstand  wrote:
> Builds and passes all tests on linux x64 with:
>
> Perl/5.18 Apache/2.2.31 mod_perl/2.10
> Perl/5.24 Apache/2.4.23 mod_perl/2.10
>
> I'm +1 on release

All successful on Win32 (x64) / VC10 with:

perl-5.25 apache-2.2.31 mod_perl-2.0.10
perl-5.25 apache 2.4.23 mod_perl-2.0.10

So it's a +1 from mee too.

Thanks, Issac!


>
> On 12/5/2016 5:58 PM, Issac Goldstand wrote:
>> After (almost) 6 years, the apreq team would like to release version
>> 2.14 of libapreq.  Please test and vote on the following tarball:
>>
>> https://home.apache.org/~issac/libapreq2-2.14.tar.gz
>> https://home.apache.org/~issac/libapreq2-2.14.tar.gz.asc
>> https://home.apache.org/~issac/libapreq2-2.14.tar.gz.md5
>>
>> Thanks,
>>   Issac
>>
>