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

On 4/1/20 11:02 AM, Joe Orton wrote: > On Wed, Apr 01, 2020 at 10:06:20AM +0200, Ruediger Pluem wrote: >> >> >> On 4/1/20 9:53 AM, Joe Orton wrote: >>> On Wed, Apr 01, 2020 at 09:24:27AM +0200, Ruediger Pluem wrote: I have checked socket, pipe and cgi buckets and none of them seem to

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

On Wed, Apr 01, 2020 at 10:06:20AM +0200, Ruediger Pluem wrote: > > > On 4/1/20 9:53 AM, Joe Orton wrote: > > On Wed, Apr 01, 2020 at 09:24:27AM +0200, Ruediger Pluem wrote: > >> I have checked socket, pipe and cgi buckets and none of them seem to > >> return EOF. In case they hit EOF they repla

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

On 4/1/20 9:53 AM, Joe Orton wrote: > On Wed, Apr 01, 2020 at 09:24:27AM +0200, Ruediger Pluem wrote: >> I have checked socket, pipe and cgi buckets and none of them seem to return >> EOF. In case they hit EOF they replace themselves with >> an immortal bucket of length 0. So above seems just a

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

On Wed, Apr 01, 2020 at 09:24:27AM +0200, Ruediger Pluem wrote: > I have checked socket, pipe and cgi buckets and none of them seem to return > EOF. In case they hit EOF they replace themselves with > an immortal bucket of length 0. So above seems just an additional safety if a > (future) morphin

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

On 3/31/20 6:52 PM, Yann Ylavic wrote: > On Tue, Mar 31, 2020 at 7:35 AM Ruediger Pluem wrote: >> >> On 3/31/20 1:19 AM, Yann Ylavic wrote: >> >> An idea would be a to have a filter that comes after all request filters >> (either as very first connection filter or in the same >> position as t

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

On 3/31/20 6:31 PM, Yann Ylavic wrote: > On Tue, Mar 31, 2020 at 7:11 AM Ruediger Pluem wrote: >> >> On 3/31/20 1:19 AM, Yann Ylavic wrote: >>> Index: server/core_filters.c >>> === >>> --- server/core_filters.c (revision 187588

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

On Tue, Mar 31, 2020 at 7:35 AM Ruediger Pluem wrote: > > On 3/31/20 1:19 AM, Yann Ylavic wrote: > > > > Yes that's the issue from the start, request filters are not supposed > > to retain anything after the EOS bucket, they are simply not called > > anymore once they return. > > Although this is

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

On Tue, Mar 31, 2020 at 7:11 AM Ruediger Pluem wrote: > > On 3/31/20 1:19 AM, Yann Ylavic wrote: > > Index: server/core_filters.c > > === > > --- server/core_filters.c (revision 1875881) > > +++ server/core_filters.c (working

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

On Tue, Mar 31, 2020 at 01:19:08AM +0200, Yann Ylavic wrote: > FWIW, attached is v2 with simpler "batching" in > ap_filter_setaside_brigade(), no spurious hunk, bb cleaned up at the > end, and APR_ENOTIMPL when called from a filter < AP_FTYPE_CONNECTION. FWIW this makes more sense to me than what'

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

On 3/31/20 1:19 AM, Yann Ylavic wrote: > On Mon, Mar 30, 2020 at 10:23 PM Ruediger Pluem wrote: >> >> On 3/26/20 2:00 PM, Yann Ylavic wrote: >>> > > [] >>> +ap_pass_brigade(c->output_filters, bb); >> >> But if request filters still have setaside brigades and these would be >> reactivated

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

On 3/31/20 1:19 AM, Yann Ylavic wrote: > Index: server/core_filters.c > === > --- server/core_filters.c (revision 1875881) > +++ server/core_filters.c (working copy) > @@ -543,6 +543,12 @@ static apr_status_t send_brigade_no

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

On Mon, Mar 30, 2020 at 10:23 PM Ruediger Pluem wrote: > > On 3/26/20 2:00 PM, Yann Ylavic wrote: >> >> Index: server/util_filter.c >> === >> --- server/util_filter.c(revision 1875498) >> +++ server/util_filter.c(worki

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

On 3/26/20 2:00 PM, Yann Ylavic wrote: > > Wouldn't that work (patch attached, passes test framework and Joe's repro)? > > Index: server/util_filter.c === --- server/util_filter.c(revision 1875498) +++ server/util_filt

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

On Sat, Mar 28, 2020 at 11:24 AM Graham Leggett wrote: > > On 27 Mar 2020, at 14:01, Yann Ylavic wrote: > > >> We need to find the reason that in a non-async case, data is being > >> setaside, and we need to fix it. > > > > Connection and network output filters shouldn't care about async or > >

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

On 27 Mar 2020, at 14:01, Yann Ylavic wrote: >> We need to find the reason that in a non-async case, data is being setaside, >> and we need to fix it. > > Connection and network output filters shouldn't care about async or > not, they just feed the pipe as much as possible, and setaside what >

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

On Fri, Mar 27, 2020 at 11:54 AM Graham Leggett wrote: > > We need to find the reason that in a non-async case, data is being setaside, > and we need to fix it. Connection and network output filters shouldn't care about async or not, they just feed the pipe as much as possible, and setaside what

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

On 26 Mar 2020, at 13:41, Joe Orton wrote: > On Thu, Mar 26, 2020 at 01:11:10AM +0200, Graham Leggett wrote: >> The question you’re asking is “why is is an async path being taken >> when AP_MPMQ_IS_ASYNC is false”. The setasides and reinstates should >> be noops in this situation. > > The "noo

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

On Thu, Mar 26, 2020 at 12:18 PM Ruediger Pluem wrote: > > On 3/26/20 12:11 AM, Graham Leggett wrote: > > > > What it does do is work around buggy request filters (set it to connection) > > or buggy connection filters (set it to network and get 2.4 behaviour).. What it does is read/morph buckets

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

On Thu, Mar 26, 2020 at 01:11:10AM +0200, Graham Leggett wrote: > The question you’re asking is “why is is an async path being taken > when AP_MPMQ_IS_ASYNC is false”. The setasides and reinstates should > be noops in this situation. The "noop" path in ap_filter_setaside_brigade is when it is pa

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

On 3/26/20 12:11 AM, Graham Leggett wrote: > On 24 Mar 2020, at 11:47, Joe Orton wrote: > >> On Tue, Mar 24, 2020 at 12:35:45AM +0200, Graham Leggett wrote: >>> The most likely reason is because: > >> If this is the correct default I guess I'd ask >> why isn't this hard-coded - at least ma

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

On 24 Mar 2020, at 11:47, Joe Orton wrote: > On Tue, Mar 24, 2020 at 12:35:45AM +0200, Graham Leggett wrote: >> 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

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

On Tue, Mar 24, 2020 at 12:35:45AM +0200, Graham Leggett wrote: > 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 th

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

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

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

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

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

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.

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

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 > notificat

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

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 "Ens

Re: async filters still borked (was Re: svn commit: r1874775 - /httpd/httpd/trunk/test/README.travis)

On 20 Mar 2020, at 15:46, Joe Orton wrote: >> Anyone found time to check >> >> https://github.com/apache/httpd/pull/88 >> >> regarding the async filter bug? > > [crickets] > > We are two months on since discussing this first. It seems quite > worrying that the async filters stuff was introd

Re: async filters still borked (was Re: svn commit: r1874775 - /httpd/httpd/trunk/test/README.travis)

On Fri, Mar 20, 2020 at 2:46 PM Joe Orton wrote: > > [crickets] > > We are two months on since discussing this first. It seems quite > worrying that the async filters stuff was introduced with apparently > nasty bugs and yet is already bitrotting on trunk with not enough people > to review and fi

Re: async filters still borked (was Re: svn commit: r1874775 - /httpd/httpd/trunk/test/README.travis)

On 3/20/20 2:46 PM, Joe Orton wrote: > On Fri, Mar 06, 2020 at 09:30:41AM +0100, Ruediger Pluem wrote: >> On 3/4/20 9:23 AM, jor...@apache.org wrote: >>> Author: jorton >>> Date: Wed Mar 4 08:23:55 2020 >>> New Revision: 1874775 >>> >>> URL: http://svn.apache.org/viewvc?rev=1874775&view=rev >>>

Re: async filters still borked (was Re: svn commit: r1874775 - /httpd/httpd/trunk/test/README.travis)

+1 from me. > On Mar 20, 2020, at 9:46 AM, Joe Orton wrote: > > On Fri, Mar 06, 2020 at 09:30:41AM +0100, Ruediger Pluem wrote: >> On 3/4/20 9:23 AM, jor...@apache.org wrote: >>> Author: jorton >>> Date: Wed Mar 4 08:23:55 2020 >>> New Revision: 1874775 >>> >>> URL: http://svn.apache.org/viewv

async filters still borked (was Re: svn commit: r1874775 - /httpd/httpd/trunk/test/README.travis)

On Fri, Mar 06, 2020 at 09:30:41AM +0100, Ruediger Pluem wrote: > On 3/4/20 9:23 AM, jor...@apache.org wrote: > > Author: jorton > > Date: Wed Mar 4 08:23:55 2020 > > New Revision: 1874775 > > > > URL: http://svn.apache.org/viewvc?rev=1874775&view=rev > > Log: > > Update docs. The expr_string.t f

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

On 3/4/20 9:23 AM, jor...@apache.org wrote: > Author: jorton > Date: Wed Mar 4 08:23:55 2020 > New Revision: 1874775 > > URL: http://svn.apache.org/viewvc?rev=1874775&view=rev > Log: > Update docs. The expr_string.t failure has not been seen since > the workaround was added AFAICT. The async