Re: svn commit: r1874775 - /httpd/httpd/trunk/test/README.travis

[Graham Leggett]

On 23 Mar 2020, at 14:53, Ruediger Pluem  wrote:

> To sum it up:
> 
> ap_request_core_filter might setaside an EOR and data before this and return,

That’s normal.

The core supports pipelining, meaning multiple requests, and therefore multiple 
EOR buckets can be lined up inside the core network filter (2.4) or any async 
filter (trunk).

There is a safety check that doesn’t allow more than X EOR buckets (and 
therefore request pools) and no more than Y file buckets (and therefore file 
descriptors) in the pipeline at once, this triggers a block until capacity has 
been freed, but other than that, we’re fine so far.

> but it is never called again,

If we were in the event MPM we would be called again by the 
ap_run_output_pending() hook, which allows the request filters to be repeatedly 
called until all the filter stacks at all levels are empty:

https://github.com/apache/httpd/blob/40d37b8a304f93cd14def4e9eab887b00a3d0e78/server/mpm/event/event.c#L1150

I see no call to ap_run_output_pending() in the worker MPM:

https://github.com/apache/httpd/blob/trunk/server/mpm/worker/worker.c

> because after EOR was
> sent only connection and later filters (c->output_filters) are called 
> afterwards, but nothing before.

The most likely reason is because:

a) http://httpd.apache.org/docs/trunk/mod/core.html#asyncfilter defaults to 
request, meaning request filters are expected to support async filters; and

b) the worker MPM doesn't call the ap_run_output_pending() hook, and so by 
definition does not support async filters.

The fix (as far as I can see) is for the worker MPM to run the 
ap_run_output_pending() hook.

What happens if you set "AsyncFilter connection”? Does it skip the problem?

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: Use of [skip ci] in commit messages to avoid Travis builds

[Rainer Jung]

Am 23.03.2020 um 20:12 schrieb Ruediger Pluem:



On 3/23/20 6:22 PM, Rainer Jung wrote:

Am 23.03.2020 um 16:56 schrieb Joe Orton:

On Sat, Feb 08, 2020 at 12:01:29PM +0100, Luca Toscano wrote:

Hi everybody,

Travis is able to read commit messages and skip the CI workflow if the
"[skip ci]" magic sequence is added somewhere. I keep forgetting about
it too, but it would be nice if we could start using it to avoid using
CI resources/workers when not needed (like docs changes, entries in
STATUS, etc..). I didn't find a way to instruct Travis to avoid
triggering a build if only certain file types are committed, so the
only solution for the moment is to manually add the aforementioned
sequence :(

It is not a big deal to trigger builds even for docs etc.., but the
ASF resources/workers are limited (and shared among projects IIUC) so
I am only suggesting to be good neighbors :) If this is totally insane
or unacceptable I'll back off and stop vouching for it I promise!


I found a new option here while playing with conditionals, we can skip
an entire build based on the commit message, it appears -

https://github.com/apache/httpd/pull/87/commits/7dd995c555ac0aea6cb3d58634750e2e076eb0cc

so this could catch a lot of the quite pointless Travis runs for STATUS
changes by filtering by commit message, something like...

if: (branch != "2.4.x" and commit_message !~ /^[Tt]ransforms$/) or
  (branch = "2.4.x" and commit_message !~ 
/^([Pp]ropose|[Vv]ote|[Tt]ransforms)$/)

anything else??


Since I forgot the [skip ci] today, I too a little time to inspect svn log for 
STATUS and arrived at the following, probably not
maintainable regexp (perl notation) for 2.4.x:

/^i?(\* ?)?([0-9] *)?([sS]ome +|[mM]ore +|[aA]dd( a)? +|[eE]asy +|[qQ]uick 
+|[sS]mall +|[uU]pdate( after)? +)?([bB]ackport(ed)?
+)?([pP]ropos(e|als?),?( *((and)?|\/|\+) *([vV]ote)?)?|[vV]otes?,?( 
*((and)?|\/|\+)
*([pP]ropos(e|als?)|[pP]romot(e|ion)s?|[cC]omments?))?|[pP]romot(e|ion)s?|[cC]omment|[nN]ote|[dD]one|[mM]erged|[cC]ommitted|[bB]ackport(ed)?)[\.:!]?(
*\[skip ci\])?$/


I think the backport stuff should not be in the list as it is often used in 
backport commits which I want to see run afterwards
through the tests for that branch.


Not sure how a multi-line commit message will be handled, ie. if the 
caret and dollar anchors are applied to every line and what happens if 
one line our of many matches.


The above pattern was meant to be applied to one-line commit messages 
only or phrased differently it should match the whole commit message, 
not only individual lines. In that case I would expect the backport part 
of the pattern to be no problem. A real backport commit message should 
also contain info like the revision number or the original commit 
message and would thus not match.


But I don't know whether the assumption about multi-line commit message 
matching is correct.


Regards,

Rainer

Re: Use of [skip ci] in commit messages to avoid Travis builds

[Ruediger Pluem]

On 3/23/20 6:22 PM, Rainer Jung wrote:
> Am 23.03.2020 um 16:56 schrieb Joe Orton:
>> On Sat, Feb 08, 2020 at 12:01:29PM +0100, Luca Toscano wrote:
>>> Hi everybody,
>>>
>>> Travis is able to read commit messages and skip the CI workflow if the
>>> "[skip ci]" magic sequence is added somewhere. I keep forgetting about
>>> it too, but it would be nice if we could start using it to avoid using
>>> CI resources/workers when not needed (like docs changes, entries in
>>> STATUS, etc..). I didn't find a way to instruct Travis to avoid
>>> triggering a build if only certain file types are committed, so the
>>> only solution for the moment is to manually add the aforementioned
>>> sequence :(
>>>
>>> It is not a big deal to trigger builds even for docs etc.., but the
>>> ASF resources/workers are limited (and shared among projects IIUC) so
>>> I am only suggesting to be good neighbors :) If this is totally insane
>>> or unacceptable I'll back off and stop vouching for it I promise!
>>
>> I found a new option here while playing with conditionals, we can skip
>> an entire build based on the commit message, it appears -
>>
>> https://github.com/apache/httpd/pull/87/commits/7dd995c555ac0aea6cb3d58634750e2e076eb0cc
>>
>> so this could catch a lot of the quite pointless Travis runs for STATUS
>> changes by filtering by commit message, something like...
>>
>> if: (branch != "2.4.x" and commit_message !~ /^[Tt]ransforms$/) or
>>  (branch = "2.4.x" and commit_message !~ 
>> /^([Pp]ropose|[Vv]ote|[Tt]ransforms)$/)
>>
>> anything else??
> 
> Since I forgot the [skip ci] today, I too a little time to inspect svn log 
> for STATUS and arrived at the following, probably not
> maintainable regexp (perl notation) for 2.4.x:
> 
> /^i?(\* ?)?([0-9] *)?([sS]ome +|[mM]ore +|[aA]dd( a)? +|[eE]asy +|[qQ]uick 
> +|[sS]mall +|[uU]pdate( after)? +)?([bB]ackport(ed)?
> +)?([pP]ropos(e|als?),?( *((and)?|\/|\+) *([vV]ote)?)?|[vV]otes?,?( 
> *((and)?|\/|\+)
> *([pP]ropos(e|als?)|[pP]romot(e|ion)s?|[cC]omments?))?|[pP]romot(e|ion)s?|[cC]omment|[nN]ote|[dD]one|[mM]erged|[cC]ommitted|[bB]ackport(ed)?)[\.:!]?(
> *\[skip ci\])?$/

I think the backport stuff should not be in the list as it is often used in 
backport commits which I want to see run afterwards
through the tests for that branch.

Regards

Rüdiger

Re: [VOTE] Release httpd-2.4.42

[Yann Ylavic]

On Mon, Mar 23, 2020 at 5:31 PM Christophe JAILLET
 wrote:
>
> Proposal made in r1875516 would also be nice to have in the next release
> if a few of us have the knowledge and time to test and vote.

Backported now ;)

Regards,
Yann.

Re: svn commit: r1875544 - /httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c

[Yann Ylavic]

On Mon, Mar 23, 2020 at 4:21 PM Rainer Jung  wrote:
>
> Thanks for the feedback. Proposed for 2.4.x a minute ago.

Thanks Rainer, backported now.


Regards,
Yann.

Re: svn commit: r1875544 - /httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c

[Yann Ylavic]

On Mon, Mar 23, 2020 at 6:11 PM Ruediger Pluem  wrote:
>
> On 3/23/20 2:48 PM, Ruediger Pluem wrote:
> >
> >
> > On 3/23/20 2:44 PM, Rainer Jung wrote:
> >> The dependency on SSL_CTX_get_min_proto_version() and 
> >> SSL_CTX_get_max_proto_version() was introduced in October by Yann's
> >> "r1868645 mod_ssl: negotiate the TLS protocol version per name based vhost 
> >> configuration".
> >>
> >> Although the set variants are available in 1.1.0, the set were added later 
> >> in 1.1.0g.
> >>
> >> Not sure, whether adjusting the version check as done now is the right 
> >> fix. At least it unbreaks building httpd against OpenSSL
> >> 1.1.0-1.1.0f.
> >>
> >> The original change has been backported to 2.4.x, so building that for the 
> >> above OpenSSL versions is currently broken.
> >
> > IMHO we should backport it then once clarified that this is the correct 
> > thing to do and ensure that it gets in 2.4.43.
> > I think this is a release blocker.

+1

>
> Question is if we should increase the Openssl version number to the same 
> level for the #if around
> ssl_callback_ClientHello and the respective callback registering code.

I think we should be good with Rainer's patch,
ssl_callback_ClientHello() depends on OpenSSL >= 1.1.1 already.

Regards,
Yann.

Re: Use of [skip ci] in commit messages to avoid Travis builds

[Rainer Jung]

Am 23.03.2020 um 16:56 schrieb Joe Orton:

On Sat, Feb 08, 2020 at 12:01:29PM +0100, Luca Toscano wrote:

Hi everybody,

Travis is able to read commit messages and skip the CI workflow if the
"[skip ci]" magic sequence is added somewhere. I keep forgetting about
it too, but it would be nice if we could start using it to avoid using
CI resources/workers when not needed (like docs changes, entries in
STATUS, etc..). I didn't find a way to instruct Travis to avoid
triggering a build if only certain file types are committed, so the
only solution for the moment is to manually add the aforementioned
sequence :(

It is not a big deal to trigger builds even for docs etc.., but the
ASF resources/workers are limited (and shared among projects IIUC) so
I am only suggesting to be good neighbors :) If this is totally insane
or unacceptable I'll back off and stop vouching for it I promise!


I found a new option here while playing with conditionals, we can skip
an entire build based on the commit message, it appears -

https://github.com/apache/httpd/pull/87/commits/7dd995c555ac0aea6cb3d58634750e2e076eb0cc

so this could catch a lot of the quite pointless Travis runs for STATUS
changes by filtering by commit message, something like...

if: (branch != "2.4.x" and commit_message !~ /^[Tt]ransforms$/) or
 (branch = "2.4.x" and commit_message !~ 
/^([Pp]ropose|[Vv]ote|[Tt]ransforms)$/)

anything else??


Since I forgot the [skip ci] today, I too a little time to inspect svn 
log for STATUS and arrived at the following, probably not maintainable 
regexp (perl notation) for 2.4.x:


/^i?(\* ?)?([0-9] *)?([sS]ome +|[mM]ore +|[aA]dd( a)? +|[eE]asy 
+|[qQ]uick +|[sS]mall +|[uU]pdate( after)? +)?([bB]ackport(ed)? 
+)?([pP]ropos(e|als?),?( *((and)?|\/|\+) *([vV]ote)?)?|[vV]otes?,?( 
*((and)?|\/|\+) 
*([pP]ropos(e|als?)|[pP]romot(e|ion)s?|[cC]omments?))?|[pP]romot(e|ion)s?|[cC]omment|[nN]ote|[dD]one|[mM]erged|[cC]ommitted|[bB]ackport(ed)?)[\.:!]?( 
*\[skip ci\])?$/


It is roughly like yours, but allows a few prefixes and suffixes around 
the magic words plus a few more of them and some frequent combinations.


Regards,

Rainer

Re: [VOTE] Release httpd-2.4.42

[Gregg Smith]

On 3/23/2020 8:18 AM, Daniel Ruggeri wrote:

Hi, all;
    Per the issues surfaced/fixed, I'll go ahead and declare this release
as dead-on-the vine. I'll target another T later this week, hopefully
after the discussion around OpenSSL versioning plays out.

    How about Thursday?



+1

Re: svn commit: r1875544 - /httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c

[Ruediger Pluem]

On 3/23/20 2:48 PM, Ruediger Pluem wrote:
> 
> 
> On 3/23/20 2:44 PM, Rainer Jung wrote:
>> The dependency on SSL_CTX_get_min_proto_version() and 
>> SSL_CTX_get_max_proto_version() was introduced in October by Yann's
>> "r1868645 mod_ssl: negotiate the TLS protocol version per name based vhost 
>> configuration".
>>
>> Although the set variants are available in 1.1.0, the set were added later 
>> in 1.1.0g.
>>
>> Not sure, whether adjusting the version check as done now is the right fix. 
>> At least it unbreaks building httpd against OpenSSL
>> 1.1.0-1.1.0f.
>>
>> The original change has been backported to 2.4.x, so building that for the 
>> above OpenSSL versions is currently broken.
> 
> IMHO we should backport it then once clarified that this is the correct thing 
> to do and ensure that it gets in 2.4.43.
> I think this is a release blocker.

Question is if we should increase the Openssl version number to the same level 
for the #if around
ssl_callback_ClientHello and the respective callback registering code.

Regards

Rüdiger

Re: [VOTE] Release httpd-2.4.42

[Christophe JAILLET]

Le 23/03/2020 à 16:18, Daniel Ruggeri a écrit :

Hi, all;
    Per the issues surfaced/fixed, I'll go ahead and declare this release
as dead-on-the vine. I'll target another T later this week, hopefully
after the discussion around OpenSSL versioning plays out.

    How about Thursday?


Hi,

Proposal made in r1875516 would also be nice to have in the next release 
if a few of us have the knowledge and time to test and vote.


CJ

Re: Use of [skip ci] in commit messages to avoid Travis builds

[Joe Orton]

On Sat, Feb 08, 2020 at 12:01:29PM +0100, Luca Toscano wrote:
> Hi everybody,
> 
> Travis is able to read commit messages and skip the CI workflow if the
> "[skip ci]" magic sequence is added somewhere. I keep forgetting about
> it too, but it would be nice if we could start using it to avoid using
> CI resources/workers when not needed (like docs changes, entries in
> STATUS, etc..). I didn't find a way to instruct Travis to avoid
> triggering a build if only certain file types are committed, so the
> only solution for the moment is to manually add the aforementioned
> sequence :(
> 
> It is not a big deal to trigger builds even for docs etc.., but the
> ASF resources/workers are limited (and shared among projects IIUC) so
> I am only suggesting to be good neighbors :) If this is totally insane
> or unacceptable I'll back off and stop vouching for it I promise!

I found a new option here while playing with conditionals, we can skip 
an entire build based on the commit message, it appears -

https://github.com/apache/httpd/pull/87/commits/7dd995c555ac0aea6cb3d58634750e2e076eb0cc

so this could catch a lot of the quite pointless Travis runs for STATUS 
changes by filtering by commit message, something like...

if: (branch != "2.4.x" and commit_message !~ /^[Tt]ransforms$/) or 
(branch = "2.4.x" and commit_message !~ 
/^([Pp]ropose|[Vv]ote|[Tt]ransforms)$/)

anything else??

Re: [VOTE] Release httpd-2.4.42

[Rainer Jung]

Am 23.03.2020 um 16:18 schrieb Daniel Ruggeri:

Hi, all;
    Per the issues surfaced/fixed, I'll go ahead and declare this release
as dead-on-the vine. I'll target another T later this week, hopefully
after the discussion around OpenSSL versioning plays out.

    How about Thursday?


Works for me.
Thanks!
Rainer

Re: svn commit: r1875544 - /httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c

[Rainer Jung]

Thanks for the feedback. Proposed for 2.4.x a minute ago.

Am 23.03.2020 um 14:48 schrieb Ruediger Pluem:



On 3/23/20 2:44 PM, Rainer Jung wrote:

The dependency on SSL_CTX_get_min_proto_version() and 
SSL_CTX_get_max_proto_version() was introduced in October by Yann's
"r1868645 mod_ssl: negotiate the TLS protocol version per name based vhost 
configuration".

Although the set variants are available in 1.1.0, the set were added later in 
1.1.0g.

Not sure, whether adjusting the version check as done now is the right fix. At 
least it unbreaks building httpd against OpenSSL
1.1.0-1.1.0f.

The original change has been backported to 2.4.x, so building that for the 
above OpenSSL versions is currently broken.


IMHO we should backport it then once clarified that this is the correct thing 
to do and ensure that it gets in 2.4.43.
I think this is a release blocker.

Regards

Rüdiger

Re: [VOTE] Release httpd-2.4.42

[Daniel Ruggeri]

Hi, all;
   Per the issues surfaced/fixed, I'll go ahead and declare this release
as dead-on-the vine. I'll target another T later this week, hopefully
after the discussion around OpenSSL versioning plays out.

   How about Thursday?

-- 
Daniel Ruggeri

On 3/19/2020 9:45 AM, Daniel Ruggeri 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.42:
> [ ] +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.
>
> The computed digests of the tarball up for vote are:
> sha1: 2e4505796dfaebcceab6ba22e5fa221e07ad488e *httpd-2.4.42.tar.gz
> sha256:
> cbac6f8211744a74f798db792b74da9f6fb5a4fbee94234cf2b01aeb9ffe57ed
> *httpd-2.4.42.tar.gz
> sha512:
> 09d0f3bd9266907eea91ac9129a3c41658929b9fd88d627c1fccceaf952548d2c3ad62099b9bcd1ae4822402c1dbda90b8bfb9f64cd5eac9f84ed249faffb837
> *httpd-2.4.42.tar.gz
>
> The SVN tag is '2.4.42' at r1875427.
>

Re: svn commit: r1875544 - /httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c

[Ruediger Pluem]

On 3/23/20 2:44 PM, Rainer Jung wrote:
> The dependency on SSL_CTX_get_min_proto_version() and 
> SSL_CTX_get_max_proto_version() was introduced in October by Yann's
> "r1868645 mod_ssl: negotiate the TLS protocol version per name based vhost 
> configuration".
> 
> Although the set variants are available in 1.1.0, the set were added later in 
> 1.1.0g.
> 
> Not sure, whether adjusting the version check as done now is the right fix. 
> At least it unbreaks building httpd against OpenSSL
> 1.1.0-1.1.0f.
> 
> The original change has been backported to 2.4.x, so building that for the 
> above OpenSSL versions is currently broken.

IMHO we should backport it then once clarified that this is the correct thing 
to do and ensure that it gets in 2.4.43.
I think this is a release blocker.

Regards

Rüdiger

Re: svn commit: r1875544 - /httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c

[Rainer Jung]

The dependency on SSL_CTX_get_min_proto_version() and 
SSL_CTX_get_max_proto_version() was introduced in October by Yann's 
"r1868645 mod_ssl: negotiate the TLS protocol version per name based 
vhost configuration".


Although the set variants are available in 1.1.0, the set were added 
later in 1.1.0g.


Not sure, whether adjusting the version check as done now is the right 
fix. At least it unbreaks building httpd against OpenSSL 1.1.0-1.1.0f.


The original change has been backported to 2.4.x, so building that for 
the above OpenSSL versions is currently broken.


Regards,

Rainer

Am 23.03.2020 um 14:33 schrieb rj...@apache.org:

Author: rjung
Date: Mon Mar 23 13:33:22 2020
New Revision: 1875544

URL: http://svn.apache.org/viewvc?rev=1875544=rev
Log:
Fix compilation breakage with OpenSSL 1.1.0 up to 1.1.0f.
SSL_CTX_get_min_proto_version() and
SSL_CTX_get_max_proto_version() were only introduced in
1.1.0g.

Modified:
 httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c

Modified: httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c?rev=1875544=1875543=1875544=diff
==
--- httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c (original)
+++ httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c Mon Mar 23 13:33:22 2020
@@ -2535,7 +2535,7 @@ static int ssl_find_vhost(void *serverna
   * from the ctx by hand
   */
  SSL_set_options(ssl, SSL_CTX_get_options(ctx));
-#if OPENSSL_VERSION_NUMBER >= 0x1010L \
+#if OPENSSL_VERSION_NUMBER >= 0x1010007fL \
  && (!defined(LIBRESSL_VERSION_NUMBER) \
  || LIBRESSL_VERSION_NUMBER >= 0x2080L)
  /*




--
kippdata
informationstechnologie GmbH   Tel: 0228 98549 -0
Bornheimer Str. 33aFax: 0228 98549 -50
53111 Bonn www.kippdata.de

HRB 8018 Amtsgericht Bonn / USt.-IdNr. DE 196 457 417
Geschäftsführer: Dr. Thomas Höfer, Rainer Jung, Sven Maurmann

Re: svn commit: r1874775 - /httpd/httpd/trunk/test/README.travis

[Ruediger Pluem]

On 3/23/20 11:32 AM, Graham Leggett wrote:
> On 23 Mar 2020, at 09:40, Ruediger Pluem  > wrote:
> 
>> In short: The async filter code currently corrupts responses in certain 
>> situations. For the whole story please look here:
>>
>> https://lists.apache.org/thread.html/r94fc303b3d2d8d0a057c150cbbcf8841b313e4de9a97b79203ac62a5%40%3Cdev.httpd.apache.org%3E
>>
>> I know that my proposal is not the final solution, but at least it avoids 
>> response corruption until a better solution is
>> available. Maybe Yann already has a better one in his latest post to the 
>> original thread.
> 
> I’ve read the thread a number of times, and I’l not been able to fully 
> understand it.
> 
> Can someone describe the problem specifically?


I guess the best description is from here (Joe at 1/7/20, 5:06 PM):

> [Tue Jan 07 13:09:32.090818 2020] [:info] [pid 117876:tid 140235421763328] 
> [client 127.0.0.1:41112] [mod_test_pass_brigade]
wrote 8192 of 8192 bytes
> [Tue Jan 07 13:09:32.090821 2020] [:info] [pid 117876:tid 140235421763328] 
> [client 127.0.0.1:41112] [mod_test_pass_brigade] done
writing 1024 of 1024 bytes
> [Tue Jan 07 13:09:32.090824 2020] [core:trace6] [pid 117876:tid 
> 140235421763328] util_filter.c(1015): [client 127.0.0.1:41112]
reinstate full brigade to full brigade in 'req_core' output filter
> [Tue Jan 07 13:09:32.090827 2020] [core:trace8] [pid 117876:tid 
> 140235421763328] util_filter.c(1133): [client 127.0.0.1:41112]
brigade contains: bytes: 49205, non-file bytes: 49205, eor buckets: 1, morphing 
buckets
> : 0
> [Tue Jan 07 13:09:32.090829 2020] [core:trace6] [pid 117876:tid 
> 140235421763328] util_filter.c(942): [client 127.0.0.1:41112]
setaside full brigade to empty brigade in 'req_core' output filter
> [Tue Jan 07 13:09:32.090835 2020] [core:trace6] [pid 117876:tid 
> 140235421763328] util_filter.c(1015): [client 127.0.0.1:41112]
reinstate full brigade to full brigade in 'core' output filter
>
> >From the above we can see there is 48K of data buffered in one of the·
> filters.  At this point we've passed through:
>
> /* Prepend buckets set aside, if any. */
> ap_filter_reinstate_brigade(f, bb, NULL);
> if (APR_BRIGADE_EMPTY(bb)) {
> return APR_SUCCESS;
> }
>
> I then dumped the contents of bb to the error log directly after:
>
> [Tue Jan 07 13:09:32.090837 2020] [core:trace1] [pid 117876:tid 
> 140235421763328] core_filters.c(373): [client 127.0.0.1:41112]
sbb: cof - bucket 0 HEAP length 1654
> [Tue Jan 07 13:09:32.090839 2020] [core:trace1] [pid 117876:tid 
> 140235421763328] core_filters.c(373): [client 127.0.0.1:41112]
sbb: cof - bucket 1 IMMORTAL length 2
> [Tue Jan 07 13:09:32.090842 2020] [core:trace1] [pid 117876:tid 
> 140235421763328] core_filters.c(373): [client 127.0.0.1:41112]
sbb: cof - bucket 2 FLUSH length 0
> [Tue Jan 07 13:09:32.090844 2020] [core:trace1] [pid 117876:tid 
> 140235421763328] core_filters.c(373): [client 127.0.0.1:41112]
sbb: cof - bucket 3 EOC length 0
>
> so the 48K does not make it back to the core output filter and is never
> sent.
>

and the analysis fro Yann (1/7/20, 7:31 PM) here:

> > [Tue Jan 07 13:09:32.090818 2020] [:info] [pid 117876:tid 140235421763328] 
> > [client 127.0.0.1:41112] [mod_test_pass_brigade]
wrote 8192 of 8192 bytes
> > [Tue Jan 07 13:09:32.090821 2020] [:info] [pid 117876:tid 140235421763328] 
> > [client 127.0.0.1:41112] [mod_test_pass_brigade]
done writing 1024 of 1024 bytes
> > [Tue Jan 07 13:09:32.090824 2020] [core:trace6] [pid 117876:tid 
> > 140235421763328] util_filter.c(1015): [client 127.0.0.1:41112]
reinstate full brigade to full brigade in 'req_core' output filter
> > [Tue Jan 07 13:09:32.090827 2020] [core:trace8] [pid 117876:tid 
> > 140235421763328] util_filter.c(1133): [client 127.0.0.1:41112]
brigade contains: bytes: 49205, non-file bytes: 49205, eor buckets: 1, morphing 
buckets
> > : 0
> > [Tue Jan 07 13:09:32.090829 2020] [core:trace6] [pid 117876:tid 
> > 140235421763328] util_filter.c(942): [client 127.0.0.1:41112]
setaside full brigade to empty brigade in 'req_core' output filter
>
> Here, the call stack is:
>   ap_process_request()
>   => ap_process_async_request()
>  => ap_process_request_after_handler()
>=> ap_pass_brigade()
>  => ap_request_core_filter()
> so ap_request_core_filter() is called with the EOR bucket, but since
> there are still pending/setaside/unsent data in the core filter then
> ap_request_core_filter() returns without passing all of its own
> pending data (including the EOR).
>
> > [Tue Jan 07 13:09:32.090835 2020] [core:trace6] [pid 117876:tid 
> > 140235421763328] util_filter.c(1015): [client 127.0.0.1:41112]
reinstate full brigade to full brigade in 'core' output filter
>
> Here, we are now at:
>   ap_process_request()
>   => ap_pass_brigade(c->output_filters, ...)
> but ap_request_core_filter() is not a connection filter (i.e. not part
> of c->output_filters), so it will never be called again.
> 

Re: [VOTE] Release httpd-2.4.42

[Jim Jagielski]

Based on this, I change my vote to -1

> On Mar 19, 2020, at 11:19 AM, Eric Covener  wrote:
> 
> On Thu, Mar 19, 2020 at 10:45 AM Daniel Ruggeri  > 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.42:
>> [ ] +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.
>> 
>> The computed digests of the tarball up for vote are:
>> sha1: 2e4505796dfaebcceab6ba22e5fa221e07ad488e *httpd-2.4.42.tar.gz
>> sha256: cbac6f8211744a74f798db792b74da9f6fb5a4fbee94234cf2b01aeb9ffe57ed
>> *httpd-2.4.42.tar.gz
>> sha512:
>> 09d0f3bd9266907eea91ac9129a3c41658929b9fd88d627c1fccceaf952548d2c3ad62099b9bcd1ae4822402c1dbda90b8bfb9f64cd5eac9f84ed249faffb837
>>  *httpd-2.4.42.tar.gz
>> 
>> The SVN tag is '2.4.42' at r1875427.
>> 
> 
> Looks like r1874288 broke my basic apxs usage w/o DESTDIR in use.
> Seems broken in my trunk sandbox too.

Re: svn commit: r1874775 - /httpd/httpd/trunk/test/README.travis

[Graham Leggett]

On 23 Mar 2020, at 09:40, Ruediger Pluem  wrote:

> In short: The async filter code currently corrupts responses in certain 
> situations. For the whole story please look here:
> 
> https://lists.apache.org/thread.html/r94fc303b3d2d8d0a057c150cbbcf8841b313e4de9a97b79203ac62a5%40%3Cdev.httpd.apache.org%3E
>  
> 
> 
> I know that my proposal is not the final solution, but at least it avoids 
> response corruption until a better solution is
> available. Maybe Yann already has a better one in his latest post to the 
> original thread.

I’ve read the thread a number of times, and I’l not been able to fully 
understand it.

Can someone describe the problem specifically?

I see lots of surprise that morphing buckets (length = -1) end up in the core - 
this is all normal. You’ll see this in the existing core filter in v2.4.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: worker MPM test failures (was Re: Still Failing: apache/httpd#190 (trunk - 894b6a1))

[Ruediger Pluem]

On 3/22/20 6:43 PM, Yann Ylavic wrote:
> +APR_BRIGADE_INSERT_TAIL(ctx->tmp_bb, bucket);
> +if (do_pass
> +|| APR_BRIGADE_EMPTY(ctx->bb)
> +|| (bucket->length == (apr_size_t)-1)

How can we have a bucket length of -1 here?
What about flush buckets? Shouldn't they cause a passing here as well?

> +|| (tmp_bb_len += bucket->length) >=
> +conf->flush_max_threshold) {
> +rv = ap_pass_brigade(f->next, ctx->tmp_bb);
> +apr_brigade_cleanup(ctx->tmp_bb);
> +if (status == APR_SUCCESS) {
> +status = rv;
>  }

Regards

Rüdiger

Re: svn commit: r1874775 - /httpd/httpd/trunk/test/README.travis

[Ruediger Pluem]

On 3/23/20 1:49 AM, Graham Leggett wrote:
> On 06 Mar 2020, at 10:30, Ruediger Pluem  wrote:
> 
>> Anyone found time to check
>>
>> https://github.com/apache/httpd/pull/88
>>
>> regarding the async filter bug?
> 
> Do these PRs come through on a mailing list anywhere? If there is no 
> notification, they’ll never get seen.
> 
> I immediately trip over "Ensure that we always pass on all we have” - that’s 
> the exact opposite of what we’re trying to do.
> 
> All the async filter stuff is, is generalising the algorithm that has long 
> existing in the core network filter, allowing any filter to take advantage of 
> the same pattern.
> 
> As soon as we try “pass all we have”, that would break the event MPM, which 
> relies on small writes in turn to work.
> 
> Can you explain the problem you’re trying to solve?
> 

In short: The async filter code currently corrupts responses in certain 
situations. For the whole story please look here:

https://lists.apache.org/thread.html/r94fc303b3d2d8d0a057c150cbbcf8841b313e4de9a97b79203ac62a5%40%3Cdev.httpd.apache.org%3E

I know that my proposal is not the final solution, but at least it avoids 
response corruption until a better solution is
available. Maybe Yann already has a better one in his latest post to the 
original thread.

Regards

Rüdiger