Still Failing: apache/httpd#1288 (2.4.x - 788be62)

[Travis CI]

Build Update for apache/httpd
-

Build: #1288
Status: Still Failing

Duration: 17 mins and 33 secs
Commit: 788be62 (2.4.x)
Author: Ruediger Pluem
Message: * Trigger CI

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1884301 
13f79535-47bb-0310-9956-ffa450edef68

View the changeset: 
https://github.com/apache/httpd/compare/2dbb4be292fa...788be62b007c

View the full build log and details: 
https://travis-ci.com/github/apache/httpd/builds/207940237?utm_medium=notification&utm_source=email


--

You can unsubscribe from build emails from the apache/httpd repository going to 
https://travis-ci.com/account/preferences/unsubscribe?repository=16806660&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.com/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.

Re: svn commit: r1884280 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_ftp.c modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c

[Graham Leggett]

On 10 Dec 2020, at 18:04, yla...@apache.org wrote:

> Author: ylavic
> Date: Thu Dec 10 16:04:34 2020
> New Revision: 1884280
> 
> URL: http://svn.apache.org/viewvc?rev=1884280&view=rev
> Log:
> Revert r1480058, -1'ed on dev@ and STATUS.
> 
> Never backported (and never will supposedly), while often creating
> merge conflicts.

You’ve just reverted a fix to an RFC violation that was picked up by the 
CoAdvisor test suite.

“Creating merge conflicts” is not a sufficient technical justification for a 
veto that results in the re-introduction of an RFC violation.

Please back this out.

> See 
> https://lists.apache.org/thread.html/be0e7bdc3510fddd2dd80accece44917eba361ef4fcc713dd0f7f7fa%401367999236%40%3Cdev.httpd.apache.org%3E
> and 
> https://lists.apache.org/thread.html/6e63271b308a2723285d288857318e7bb51b6756690514d9bc75a71b%401371148914%40%3Ccvs.httpd.apache.org%3E
>  
> 

Please resolve the discussion above.

The last on the thread is that Roy was asked for advice, but he was busy. In 
the light of RFC7230 it would be useful to get a new answer on this question.

Regards,
Graham
—

Re: Still Failing: apache/httpd#1288 (2.4.x - 788be62)

[Ruediger Pluem]

On 12/11/20 12:30 PM, Travis CI wrote:
> apache
> 
> /
> 
> httpd
> 
> 
> 
> branch icon2.4.x 
> 
> build has failed
> Build #1288 is still failing 
> 
> arrow to build time
> clock icon17 mins and 33 secs

I think this is exposed by r1883752 
(http://svn.apache.org/viewvc?view=revision&revision=1883752), but the real 
root cause is the
missing backport of r1876626 
(http://svn.apache.org/viewvc?view=revision&revision=1876626) to 2.4.x. 
Thoughts?

Regards

Rüdiger

Re: svn commit: r1884280 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_ftp.c modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c

[Yann Ylavic]

On Fri, Dec 11, 2020 at 12:49 PM Graham Leggett  wrote:
>
> On 10 Dec 2020, at 18:04, yla...@apache.org wrote:
>
> Author: ylavic
> Date: Thu Dec 10 16:04:34 2020
> New Revision: 1884280
>
> URL: http://svn.apache.org/viewvc?rev=1884280&view=rev
> Log:
> Revert r1480058, -1'ed on dev@ and STATUS.
>
> Never backported (and never will supposedly), while often creating
> merge conflicts.
>
> You’ve just reverted a fix to an RFC violation that was picked up by the 
> CoAdvisor test suite.

Where is this test suite?
Which RFC violation, a proxy socket connection error should return 504
Gateway Timeout??
I see that RFC2616 14.9.4 is about cache, why don't you fix this in mod_cache?

>
> “Creating merge conflicts” is not a sufficient technical justification for a 
> veto that results in the re-introduction of an RFC violation.
>
> Please back this out.
>
> See 
> https://lists.apache.org/thread.html/be0e7bdc3510fddd2dd80accece44917eba361ef4fcc713dd0f7f7fa%401367999236%40%3Cdev.httpd.apache.org%3E
> and 
> https://lists.apache.org/thread.html/6e63271b308a2723285d288857318e7bb51b6756690514d9bc75a71b%401371148914%40%3Ccvs.httpd.apache.org%3E
>
> Please resolve the discussion above.

You should do that, it's not my veto. Failing to resolve the
discussion, the commit should be reverted right?

>
> The last on the thread is that Roy was asked for advice, but he was busy. In 
> the light of RFC7230 it would be useful to get a new answer on this question.

Sure.


Regards;
Yann.

Re: svn commit: r1884280 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_ftp.c modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c

[Yann Ylavic]

On Fri, Dec 11, 2020 at 1:13 PM Yann Ylavic  wrote:
>
> I see that RFC2616 14.9.4 is about cache, why don't you fix this in mod_cache?

If you need a hint from mod_proxy (when it failed to forward the
request), you could (for instance) add a r->notes for mod_cache to do
the right thing.
But I don't see why a connection aborted by the backend qualifies as
Gateway Timeout.

Regards;
Yann.

Re: Still Failing: apache/httpd#1288 (2.4.x - 788be62)

[Yann Ylavic]

On Fri, Dec 11, 2020 at 12:59 PM Ruediger Pluem  wrote:
>
> On 12/11/20 12:30 PM, Travis CI wrote:
> >
> > branch icon2.4.x 
> >
> > build has failed
>
> I think this is exposed by r1883752 
> (http://svn.apache.org/viewvc?view=revision&revision=1883752),

The old code would also have abort()ed on a NULL pool.

> but the real root cause is the
> missing backport of r1876626 
> (http://svn.apache.org/viewvc?view=revision&revision=1876626) to 2.4.x. 
> Thoughts?

Good catch! +1 for backport.


Regards;
Yann.

Re: Still Failing: apache/httpd#1288 (2.4.x - 788be62)

[Joe Orton]

On Fri, Dec 11, 2020 at 01:48:39PM +0100, Yann Ylavic wrote:
> On Fri, Dec 11, 2020 at 12:59 PM Ruediger Pluem  wrote:
> >
> > On 12/11/20 12:30 PM, Travis CI wrote:
> > >
> > > branch icon2.4.x 
> > >
> > > build has failed
> >
> > I think this is exposed by r1883752 
> > (http://svn.apache.org/viewvc?view=revision&revision=1883752),
> 
> The old code would also have abort()ed on a NULL pool.
> 
> > but the real root cause is the
> > missing backport of r1876626 
> > (http://svn.apache.org/viewvc?view=revision&revision=1876626) to 2.4.x. 
> > Thoughts?
> 
> Good catch! +1 for backport.

+1 from me too, can we get a third?

Re: Still Failing: apache/httpd#1288 (2.4.x - 788be62)

[Yann Ylavic]

On Fri, Dec 11, 2020 at 3:04 PM Joe Orton  wrote:
>
> On Fri, Dec 11, 2020 at 01:48:39PM +0100, Yann Ylavic wrote:
> > On Fri, Dec 11, 2020 at 12:59 PM Ruediger Pluem  wrote:
> > >
> > > On 12/11/20 12:30 PM, Travis CI wrote:
> > > >
> > > > branch icon2.4.x 
> > > >
> > > > build has failed
> > >
> > > I think this is exposed by r1883752 
> > > (http://svn.apache.org/viewvc?view=revision&revision=1883752),
> >
> > The old code would also have abort()ed on a NULL pool.
> >
> > > but the real root cause is the
> > > missing backport of r1876626 
> > > (http://svn.apache.org/viewvc?view=revision&revision=1876626) to 2.4.x. 
> > > Thoughts?
> >
> > Good catch! +1 for backport.
>
> +1 from me too, can we get a third?

Those:

  *) core: reset ap_runtime_dir to NULL after AP_SQ_MS_DESTROY_CONFIG.
  *) mod_http2: stop/wait the workers threads before their pool is killed.

in STATUS already are also about making the ci pass on 2.4.x with the
same set as trunk.

+1s are welcome (and easy I think) there too :)


Regards;
Yann.

Re: svn commit: r1884280 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_ftp.c modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c

[Ruediger Pluem]

On 12/11/20 1:13 PM, Yann Ylavic wrote:
> On Fri, Dec 11, 2020 at 12:49 PM Graham Leggett  wrote:
>>
>> On 10 Dec 2020, at 18:04, yla...@apache.org wrote:
>>
>> Author: ylavic
>> Date: Thu Dec 10 16:04:34 2020
>> New Revision: 1884280
>>
>> URL: http://svn.apache.org/viewvc?rev=1884280&view=rev
>> Log:
>> Revert r1480058, -1'ed on dev@ and STATUS.
>>
>> Never backported (and never will supposedly), while often creating
>> merge conflicts.
>>
>> You’ve just reverted a fix to an RFC violation that was picked up by the 
>> CoAdvisor test suite.
> 
> Where is this test suite?
> Which RFC violation, a proxy socket connection error should return 504
> Gateway Timeout??
> I see that RFC2616 14.9.4 is about cache, why don't you fix this in mod_cache?
> 
>>
>> “Creating merge conflicts” is not a sufficient technical justification for a 
>> veto that results in the re-introduction of an RFC violation.
>>
>> Please back this out.
>>
>> See 
>> https://lists.apache.org/thread.html/be0e7bdc3510fddd2dd80accece44917eba361ef4fcc713dd0f7f7fa%401367999236%40%3Cdev.httpd.apache.org%3E
>> and 
>> https://lists.apache.org/thread.html/6e63271b308a2723285d288857318e7bb51b6756690514d9bc75a71b%401371148914%40%3Ccvs.httpd.apache.org%3E
>>
>> Please resolve the discussion above.

Just as an update for restarting the discussion:

Old RFC2616 Section New RFC and section Link
14.9.4  RFC7234, 5.2.2.1
https://tools.ietf.org/html/rfc7234#section-5.2.2
10.5.3  RFC7231, 6.6.3  
https://tools.ietf.org/html/rfc7231#section-6.6.3
10.5.5  RFC7231, 6.6.5  
https://tools.ietf.org/html/rfc7231#section-6.6.5

After rereading the sections on the new RFC's my opinion is still the same as in

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

IMHO RFC7231, 6.6.3 and RFC7231, 6.6.5 apply for the proxy/gateway. In the 
revalidate case (RFC7234, 5.2.2.1) the issue for the
cache may be even wider: What if the reply on the revalidation request from the 
backend is not cachable for whatever reason (like
the 502 here without appropriate headers that allow caching)?
Does the cache just pass the reply on and does not update its cache? Does it 
remove the stale entry from the cache?

Apart from this the proxy could add a note to r->notes if there was a network 
issue with the backend such that the cache can reply
with 504 in this case. But of course this only helps in the case that the next 
hop was not reachable. If the 502 is created by a
further gateway between us and the origin server the issue remains.

> 
> You should do that, it's not my veto. Failing to resolve the
> discussion, the commit should be reverted right?
> 
>>
>> The last on the thread is that Roy was asked for advice, but he was busy. In 
>> the light of RFC7230 it would be useful to get a new answer on this question.
> 
> Sure.

Can you please help us resolving this Roy?

Regards

Rüdiger

Re: Still Failing: apache/httpd#1288 (2.4.x - 788be62)

[Ruediger Pluem]

On 12/11/20 3:11 PM, Yann Ylavic wrote:
> On Fri, Dec 11, 2020 at 3:04 PM Joe Orton  wrote:
>>
>> On Fri, Dec 11, 2020 at 01:48:39PM +0100, Yann Ylavic wrote:
>>> On Fri, Dec 11, 2020 at 12:59 PM Ruediger Pluem  wrote:

 On 12/11/20 12:30 PM, Travis CI wrote:
>
> branch icon2.4.x 
>
> build has failed

 I think this is exposed by r1883752 
 (http://svn.apache.org/viewvc?view=revision&revision=1883752),
>>>
>>> The old code would also have abort()ed on a NULL pool.
>>>
 but the real root cause is the
 missing backport of r1876626 
 (http://svn.apache.org/viewvc?view=revision&revision=1876626) to 2.4.x. 
 Thoughts?
>>>
>>> Good catch! +1 for backport.
>>
>> +1 from me too, can we get a third?

+1 from me.

> 
> Those:
> 
>   *) core: reset ap_runtime_dir to NULL after AP_SQ_MS_DESTROY_CONFIG.
>   *) mod_http2: stop/wait the workers threads before their pool is killed.

I will have a look separately.

Regards

Rüdiger

> 
> in STATUS already are also about making the ci pass on 2.4.x with the
> same set as trunk.
> 
> +1s are welcome (and easy I think) there too :)
> 
> 
> Regards;
> Yann.
> 

Re: Still Failing: apache/httpd#1288 (2.4.x - 788be62)

[Ruediger Pluem]

On 12/11/20 3:31 PM, Ruediger Pluem wrote:
> 
> 
> On 12/11/20 3:11 PM, Yann Ylavic wrote:
>> On Fri, Dec 11, 2020 at 3:04 PM Joe Orton  wrote:
>>>
>>> On Fri, Dec 11, 2020 at 01:48:39PM +0100, Yann Ylavic wrote:
 On Fri, Dec 11, 2020 at 12:59 PM Ruediger Pluem  wrote:
>
> On 12/11/20 12:30 PM, Travis CI wrote:
>>
>> branch icon2.4.x 
>>
>> build has failed
>
> I think this is exposed by r1883752 
> (http://svn.apache.org/viewvc?view=revision&revision=1883752),

 The old code would also have abort()ed on a NULL pool.

> but the real root cause is the
> missing backport of r1876626 
> (http://svn.apache.org/viewvc?view=revision&revision=1876626) to 2.4.x. 
> Thoughts?

 Good catch! +1 for backport.
>>>
>>> +1 from me too, can we get a third?
> 
> +1 from me.
> 
>>
>> Those:
>>
>>   *) core: reset ap_runtime_dir to NULL after AP_SQ_MS_DESTROY_CONFIG.
>>   *) mod_http2: stop/wait the workers threads before their pool is killed.
> 
> I will have a look separately.
> 

Already done by others :-)

Regards

Rüdiger

Re: Still Failing: apache/httpd#1288 (2.4.x - 788be62)

[Yann Ylavic]

On Fri, Dec 11, 2020 at 3:35 PM Ruediger Pluem  wrote:
>
> On 12/11/20 3:31 PM, Ruediger Pluem wrote:
> >
> >
> > On 12/11/20 3:11 PM, Yann Ylavic wrote:
> >> On Fri, Dec 11, 2020 at 3:04 PM Joe Orton  wrote:
> >>>
> >>> On Fri, Dec 11, 2020 at 01:48:39PM +0100, Yann Ylavic wrote:
>  On Fri, Dec 11, 2020 at 12:59 PM Ruediger Pluem  
>  wrote:
> >
> > On 12/11/20 12:30 PM, Travis CI wrote:
> >>
> >> branch icon2.4.x 
> >>
> >> build has failed
> >
> > I think this is exposed by r1883752 
> > (http://svn.apache.org/viewvc?view=revision&revision=1883752),
> 
>  The old code would also have abort()ed on a NULL pool.
> 
> > but the real root cause is the
> > missing backport of r1876626 
> > (http://svn.apache.org/viewvc?view=revision&revision=1876626) to 2.4.x. 
> > Thoughts?
> 
>  Good catch! +1 for backport.
> >>>
> >>> +1 from me too, can we get a third?
> >
> > +1 from me.
> >
> >>
> >> Those:
> >>
> >>   *) core: reset ap_runtime_dir to NULL after AP_SQ_MS_DESTROY_CONFIG.
> >>   *) mod_http2: stop/wait the workers threads before their pool is killed.
> >
> > I will have a look separately.
> >
>
> Already done by others :-)

We are too fast, even travis can't cope :)

Re: Still Failing: apache/httpd#1288 (2.4.x - 788be62)

[Stefan Eissing]

You guys are awesome! ;-)

> Am 11.12.2020 um 15:38 schrieb Yann Ylavic :
> 
> On Fri, Dec 11, 2020 at 3:35 PM Ruediger Pluem  wrote:
>> 
>> On 12/11/20 3:31 PM, Ruediger Pluem wrote:
>>> 
>>> 
>>> On 12/11/20 3:11 PM, Yann Ylavic wrote:
 On Fri, Dec 11, 2020 at 3:04 PM Joe Orton  wrote:
> 
> On Fri, Dec 11, 2020 at 01:48:39PM +0100, Yann Ylavic wrote:
>> On Fri, Dec 11, 2020 at 12:59 PM Ruediger Pluem  
>> wrote:
>>> 
>>> On 12/11/20 12:30 PM, Travis CI wrote:
 
 branch icon2.4.x 
 
 build has failed
>>> 
>>> I think this is exposed by r1883752 
>>> (http://svn.apache.org/viewvc?view=revision&revision=1883752),
>> 
>> The old code would also have abort()ed on a NULL pool.
>> 
>>> but the real root cause is the
>>> missing backport of r1876626 
>>> (http://svn.apache.org/viewvc?view=revision&revision=1876626) to 2.4.x. 
>>> Thoughts?
>> 
>> Good catch! +1 for backport.
> 
> +1 from me too, can we get a third?
>>> 
>>> +1 from me.
>>> 
 
 Those:
 
  *) core: reset ap_runtime_dir to NULL after AP_SQ_MS_DESTROY_CONFIG.
  *) mod_http2: stop/wait the workers threads before their pool is killed.
>>> 
>>> I will have a look separately.
>>> 
>> 
>> Already done by others :-)
> 
> We are too fast, even travis can't cope :)

Broken: apache/httpd#1291 (trunk - aa3b99e)

[Travis CI]

Build Update for apache/httpd
-

Build: #1291
Status: Broken

Duration: 17 mins and 32 secs
Commit: aa3b99e (trunk)
Author: Yann Ylavic
Message: ci: generate as many core files as there are crashes.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1884306 
13f79535-47bb-0310-9956-ffa450edef68

View the changeset: 
https://github.com/apache/httpd/compare/2bc917d4e938...aa3b99e92571

View the full build log and details: 
https://travis-ci.com/github/apache/httpd/builds/208037540?utm_medium=notification&utm_source=email


--

You can unsubscribe from build emails from the apache/httpd repository going to 
https://travis-ci.com/account/preferences/unsubscribe?repository=16806660&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.com/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.

Still Failing: apache/httpd#1292 (2.4.x - 5925ff2)

[Travis CI]

Build Update for apache/httpd
-

Build: #1292
Status: Still Failing

Duration: 12 mins and 53 secs
Commit: 5925ff2 (2.4.x)
Author: Yann Ylavic
Message: Merge r1883708, r1884208 from trunk:

core: reset ap_runtime_dir to NULL after AP_SQ_MS_DESTROY_CONFIG.

ap_runtime_dir_relative() might reuse ap_runtime_dir from previously cleared
pconf otherwise.


Rearrange and clear global core config state allocated out of pconf
from a single cleanup:

* server/core.c (reset_config): Clear ap_runtime_dir here, rather than
  in register_hooks.


Submitted by: ylavic, jorton
Reviewed by: ylavic, jorton, covener


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1884316 
13f79535-47bb-0310-9956-ffa450edef68

View the changeset: 
https://github.com/apache/httpd/compare/e4b402be89a3...5925ff28a421

View the full build log and details: 
https://travis-ci.com/github/apache/httpd/builds/208081207?utm_medium=notification&utm_source=email


--

You can unsubscribe from build emails from the apache/httpd repository going to 
https://travis-ci.com/account/preferences/unsubscribe?repository=16806660&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.com/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.

Still Failing: apache/httpd#1293 (2.4.x - fd70b17)

[Travis CI]

Build Update for apache/httpd
-

Build: #1293
Status: Still Failing

Duration: 12 mins and 7 secs
Commit: fd70b17 (2.4.x)
Author: Yann Ylavic
Message: Merge r1884169, r1884170 from trunk:

mod_http2: Rename server_pool as pchild in h2_workers_create()

To clarify which parent pool the workers threads have.
And add a comment about workers_pool_cleanup()'s role and when it runs.

No functional change.


mod_http2: stop/wait the workers threads before their pool is killed.

There shouldn't be any worker thread active when pchild is destroyed (thus each
thread's pool), so register workers_pool_cleanup as a pre_cleanup of pchild.

This is to avoid races like the below stacktrace, where slot_run() threads
are still running when clean_child_exit() is called.

Thread 23 (Thread 0x7f4865b79800 (LWP 3740)):
#0  0x7f4864dec449 in pthread_cond_destroy@@GLIBC_2.3.2 () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#1  0x7f4865020117 in run_cleanups (cref=) at 
memory/unix/apr_pools.c:2629
#2  pool_clear_debug (pool=pool@entry=0x558a5297e4a0, file_line=0x558a5237456b 
"event.c:757") at memory/unix/apr_pools.c:1830
#3  0x7f486501ffee in pool_destroy_debug (pool=0x558a5297e4a0, 
file_line=) at memory/unix/apr_pools.c:1915
#4  0x7f48650200f0 in pool_clear_debug (pool=pool@entry=0x558a52a41070, 
file_line=0x558a5237456b "event.c:757") at memory/unix/apr_pools.c:1827
#5  0x7f486501ffee in pool_destroy_debug (pool=0x558a52a41070, 
file_line=) at memory/unix/apr_pools.c:1915
#6  0x7f486502085c in apr_pool_destroy_debug (pool=, 
file_line=) at memory/unix/apr_pools.c:1957
#7  0x558a52326cfc in clean_child_exit (code=0) at event.c:757
#8  0x558a52327969 in child_main (child_num_arg=child_num_arg@entry=1, 
child_bucket=child_bucket@entry=0) at event.c:2926
#9  0x558a52327ce5 in make_child (s=0x558a52c9f840, slot=slot@entry=1, 
bucket=0) at event.c:2992
#10 0x558a52327d4c in startup_children (number_to_start=2, 
number_to_start@entry=3) at event.c:3015
#11 0x558a523289ac in event_run (_pconf=, 
plog=0x558a5273ce00, s=0x558a52c9f840) at event.c:3374
#12 0x558a5233e91e in ap_run_mpm (pconf=0x558a5270cbe0, 
plog=0x558a5273ce00, s=0x558a52c9f840) at mpm_common.c:100
#13 0x558a5231b763 in main (argc=, argv=) at 
main.c:844

Thread 2 (Thread 0x7f4840b70700 (LWP 3836)):
#0  0x7f4864dec9f3 in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#1  0x7f486501f65d in apr_thread_cond_wait (cond=, 
mutex=) at locks/unix/thread_cond.c:68
#2  0x7f484e14ae4a in get_next (slot=0x558a528d5fe0) at h2_workers.c:209
#3  slot_run (thread=0x558a52828b30, wctx=0x558a528d5fe0) at h2_workers.c:228
#4  0x7f4864de66db in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#5  0x7f4864b0f88f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 1 (Thread 0x7f4841b72700 (LWP 3834)):
#0  0x7f4864a2ce97 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7f4864a2e801 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x7f4865020865 in apr_pool_destroy_debug (pool=, 
file_line=) at memory/unix/apr_pools.c:1955
#3  0x7f486502b536 in apr_thread_exit (thd=thd@entry=0x558a52ba8980, 
retval=retval@entry=0) at threadproc/unix/thread.c:206
#4  0x7f484e14aec6 in slot_run (thread=0x558a52ba8980, wctx=0x558a528d6060) 
at h2_workers.c:248
#5  0x7f4864de66db in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#6  0x7f4864b0f88f in clone () from /lib/x86_64-linux-gnu/libc.so.6


Submitted by: ylavic
Reviewed by: ylavic, jorton, covener


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1884318 
13f79535-47bb-0310-9956-ffa450edef68

View the changeset: 
https://github.com/apache/httpd/compare/cbfd1a9d871b...fd70b17ea50e

View the full build log and details: 
https://travis-ci.com/github/apache/httpd/builds/208081993?utm_medium=notification&utm_source=email


--

You can unsubscribe from build emails from the apache/httpd repository going to 
https://travis-ci.com/account/preferences/unsubscribe?repository=16806660&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.com/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.

Fixed: apache/httpd#1294 (2.4.x - 03b7224)

[Travis CI]

Build Update for apache/httpd
-

Build: #1294
Status: Fixed

Duration: 12 mins and 19 secs
Commit: 03b7224 (2.4.x)
Author: Yann Ylavic
Message: Merge r1876626 from trunk:

* server/mpm/prefork/prefork.c (prefork_pre_config): Use pconf as
  passed to the hook with ap_fatal_signal_child_setup, since
  prefork.c's pconf "global" is not set until the (later) open_logs
  hook, and if built as a DSO it may be reset inbetween.

* server/mpm/motorz/motorz.c (motorz_pre_config): Likewise.

[event and worker do not appear to have the same issue]


Submitted by: jorton
Reviewed by: 
https://lists.apache.org/thread.html/rc43315d87ac9bb92a6e0e4068d7680e7044df0a1640d514fd40f19fd%40%3Cdev.httpd.apache.org%3E


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1884320 
13f79535-47bb-0310-9956-ffa450edef68

View the changeset: 
https://github.com/apache/httpd/compare/4601fa3ddb60...03b7224de00e

View the full build log and details: 
https://travis-ci.com/github/apache/httpd/builds/208083353?utm_medium=notification&utm_source=email


--

You can unsubscribe from build emails from the apache/httpd repository going to 
https://travis-ci.com/account/preferences/unsubscribe?repository=16806660&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.com/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.

Fixed: apache/httpd#1295 (2.4.x - 696491d)

[Travis CI]

Build Update for apache/httpd
-

Build: #1295
Status: Fixed

Duration: 11 mins and 59 secs
Commit: 696491d (2.4.x)
Author: Yann Ylavic
Message: ci: ASan and prefork w/ mod_http2 should be good for 2.4.x now.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1884321 
13f79535-47bb-0310-9956-ffa450edef68

View the changeset: 
https://github.com/apache/httpd/compare/03b7224de00e...696491d23fab

View the full build log and details: 
https://travis-ci.com/github/apache/httpd/builds/208084144?utm_medium=notification&utm_source=email


--

You can unsubscribe from build emails from the apache/httpd repository going to 
https://travis-ci.com/account/preferences/unsubscribe?repository=16806660&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.com/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.

Errored: apache/httpd#1296 (2.4.x - fb69437)

[Travis CI]

Build Update for apache/httpd
-

Build: #1296
Status: Errored

Duration: 24 mins and 54 secs
Commit: fb69437 (2.4.x)
Author: Yann Ylavic
Message: yml syntax after r1884321.

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1884323 
13f79535-47bb-0310-9956-ffa450edef68

View the changeset: 
https://github.com/apache/httpd/compare/696491d23fab...fb6943738065

View the full build log and details: 
https://travis-ci.com/github/apache/httpd/builds/208084665?utm_medium=notification&utm_source=email


--

You can unsubscribe from build emails from the apache/httpd repository going to 
https://travis-ci.com/account/preferences/unsubscribe?repository=16806660&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.com/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.

Re: svn commit: r1884280 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_ftp.c modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c

[Roy T. Fielding]

> On Dec 11, 2020, at 6:28 AM, Ruediger Pluem  wrote:
> On 12/11/20 1:13 PM, Yann Ylavic wrote:
>> On Fri, Dec 11, 2020 at 12:49 PM Graham Leggett  wrote:
>>> 
>>> On 10 Dec 2020, at 18:04, yla...@apache.org wrote:
>>> 
>>> Author: ylavic
>>> Date: Thu Dec 10 16:04:34 2020
>>> New Revision: 1884280
>>> 
>>> URL: http://svn.apache.org/viewvc?rev=1884280&view=rev
>>> Log:
>>> Revert r1480058, -1'ed on dev@ and STATUS.
>>> 
>>> Never backported (and never will supposedly), while often creating
>>> merge conflicts.
>>> 
>>> You’ve just reverted a fix to an RFC violation that was picked up by the 
>>> CoAdvisor test suite.
>> 
>> Where is this test suite?
>> Which RFC violation, a proxy socket connection error should return 504
>> Gateway Timeout??
>> I see that RFC2616 14.9.4 is about cache, why don't you fix this in 
>> mod_cache?
>> 
>>> 
>>> “Creating merge conflicts” is not a sufficient technical justification for 
>>> a veto that results in the re-introduction of an RFC violation.
>>> 
>>> Please back this out.
>>> 
>>> See 
>>> https://lists.apache.org/thread.html/be0e7bdc3510fddd2dd80accece44917eba361ef4fcc713dd0f7f7fa%401367999236%40%3Cdev.httpd.apache.org%3E
>>> and 
>>> https://lists.apache.org/thread.html/6e63271b308a2723285d288857318e7bb51b6756690514d9bc75a71b%401371148914%40%3Ccvs.httpd.apache.org%3E
>>> 
>>> Please resolve the discussion above.
> 
> Just as an update for restarting the discussion:
> 
> Old RFC2616 Section   New RFC and section Link
> 14.9.4RFC7234, 5.2.2.1
> https://tools.ietf.org/html/rfc7234#section-5.2.2 
> 
> 10.5.3RFC7231, 6.6.3  
> https://tools.ietf.org/html/rfc7231#section-6.6.3 
> 
> 10.5.5RFC7231, 6.6.5  
> https://tools.ietf.org/html/rfc7231#section-6.6.5 
> 

Heh, sorry, the current version is

  
https://httpwg.org/http-core/draft-ietf-httpbis-cache-latest.html#cache-response-directive.must-revalidate
 

  
https://httpwg.org/http-core/draft-ietf-httpbis-cache-latest.html#rfc.section.4.3.3
 


  
https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#status.502
 


and we have until Monday to fix it, if needed.

> After rereading the sections on the new RFC's my opinion is still the same as 
> in
> 
> https://lists.apache.org/thread.html/be0e7bdc3510fddd2dd80accece44917eba361ef4fcc713dd0f7f7fa%401367999236%40%3Cdev.httpd.apache.org%3E
>  
> 
> 
> IMHO RFC7231, 6.6.3 and RFC7231, 6.6.5 apply for the proxy/gateway. In the 
> revalidate case (RFC7234, 5.2.2.1) the issue for the
> cache may be even wider: What if the reply on the revalidation request from 
> the backend is not cachable for whatever reason (like
> the 502 here without appropriate headers that allow caching)?
> Does the cache just pass the reply on and does not update its cache? Does it 
> remove the stale entry from the cache?
> 
> Apart from this the proxy could add a note to r->notes if there was a network 
> issue with the backend such that the cache can reply
> with 504 in this case. But of course this only helps in the case that the 
> next hop was not reachable. If the 502 is created by a
> further gateway between us and the origin server the issue remains.

That is too many questions. The purpose of the cache requirement is so that the 
cache
does not deliver a non-validated entry after receiving a failed validation. It 
doesn't really
matter what code is returned so long as it is 5xx, so the specs are 
over-constraining here.

The CoAdvisor test suite is overly pedantic.

And, as stated, this only applies when the request contains max-revalidate and 
the
action being done is a cache revalidation. No other code should behave this way.

>> You should do that, it's not my veto. Failing to resolve the
>> discussion, the commit should be reverted right?
>> 
>>> 
>>> The last on the thread is that Roy was asked for advice, but he was busy. 
>>> In the light of RFC7230 it would be useful to get a new answer on this 
>>> question.
>> 
>> Sure.
> 
> Can you please help us resolving this Roy?

Reverting the change is the correct call, regardless, but it is also the right 
choice.
I have filed a bug on the Cache spec to change that MUST send 504 to a MUST 
send 5xx.

   https://github.com/httpwg/http-core/issues/608 


If you think we need to change other things in the specs, please file bugs now.

Errored: apache/httpd#1299 (trunk - da49d78)

[Travis CI]

Build Update for apache/httpd
-

Build: #1299
Status: Errored

Duration: 7 hrs, 7 mins, and 4 secs
Commit: da49d78 (trunk)
Author: Yann Ylavic
Message: Fix bash syntax in travis_run_linux.sh.

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1884326 
13f79535-47bb-0310-9956-ffa450edef68

View the changeset: 
https://github.com/apache/httpd/compare/aa3b99e92571...da49d78635db

View the full build log and details: 
https://travis-ci.com/github/apache/httpd/builds/208125114?utm_medium=notification&utm_source=email


--

You can unsubscribe from build emails from the apache/httpd repository going to 
https://travis-ci.com/account/preferences/unsubscribe?repository=16806660&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.com/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.

Passed: apache/httpd#1303 (2.4.x - f6931e1)

[Travis CI]

Build Update for apache/httpd
-

Build: #1303
Status: Passed

Duration: 41 mins and 12 secs
Commit: f6931e1 (2.4.x)
Author: Yann Ylavic
Message: ci: disable ASan pool-debug for now.

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1884339 
13f79535-47bb-0310-9956-ffa450edef68

View the changeset: 
https://github.com/apache/httpd/compare/3e82736734d8...f6931e1b1417

View the full build log and details: 
https://travis-ci.com/github/apache/httpd/builds/208258330?utm_medium=notification&utm_source=email


--

You can unsubscribe from build emails from the apache/httpd repository going to 
https://travis-ci.com/account/preferences/unsubscribe?repository=16806660&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.com/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.

Errored: apache/httpd#1297 (2.4.x - 3e82736)

[Travis CI]

Build Update for apache/httpd
-

Build: #1297
Status: Errored

Duration: ?
Commit: 3e82736 (2.4.x)
Author: Yann Ylavic
Message: Promote.

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1884325 
13f79535-47bb-0310-9956-ffa450edef68

View the changeset: 
https://github.com/apache/httpd/compare/fb6943738065...3e82736734d8

View the full build log and details: 
https://travis-ci.com/github/apache/httpd/builds/208085522?utm_medium=notification&utm_source=email


--

You can unsubscribe from build emails from the apache/httpd repository going to 
https://travis-ci.com/account/preferences/unsubscribe?repository=16806660&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.com/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.