On Tue, Aug 19, 2025 at 2:45 PM wrote:
>
> Author: rpluem
> Date: Tue Aug 19 12:45:15 2025
> New Revision: 1927885
>
> Log:
> Make the value set for the socket option TCP_DEFER_ACCEPT configurable
>
> * include/ap_listen.h:
> - Add prototype for include/ap_listen.heraccept
> - Wire in new dire
On Mon, Jul 21, 2025 at 2:30 PM Eric Covener wrote:
>
> I would like to call a VOTE over the next few days to release
> this candidate tarball httpd-2.4.65-rc3 as 2.4.65:
+1, tested on Debian 12 & 13/sid (tests framework).
Thanks Eric!
On Mon, Jul 7, 2025 at 5:57 PM Eric Covener wrote:
>
> I would like to call a VOTE over the next few days to release
> this candidate tarball httpd-2.4.64-rc2 as 2.4.64:
[X] +1: It's not just good, it's good enough!
Tested on Debian 12 & 13/sid, checksums/sigs OK, tests framework passes.
Thanks
On Mon, Jul 7, 2025 at 5:30 PM Eric Covener wrote:
>
> On Mon, Jul 7, 2025 at 11:22 AM Alexander Gerasimov via dev
> wrote:
>>
>> Dear httpd devs,
>>
>> Can we add a check for CURLSSLOPT_NO_REVOKE in mod_md?
>>
>> Specifically, I have the following error on curl < 7.44.0:
>>
>> md_curl.c: In fun
On Mon, Jun 2, 2025 at 1:25 PM Ruediger Pluem wrote:
>
> On 5/22/25 3:29 PM, jean-frederic clere wrote:
> > On 5/22/25 2:37 PM, Yann Ylavic wrote:
> >> On Thu, May 22, 2025 at 9:39 AM jean-frederic clere
> >> wrote:
> >>>
> >>> On 5/20/25 2
On Thu, May 22, 2025 at 9:39 AM jean-frederic clere wrote:
>
> On 5/20/25 2:48 PM, Yann Ylavic wrote:
> > On Tue, May 20, 2025 at 12:03 PM jean-frederic clere
> > wrote:
> >>
> >> Find the configuration I have used to reproduce the customer issue,
>
On Tue, May 20, 2025 at 12:03 PM jean-frederic clere wrote:
>
> Find the configuration I have used to reproduce the customer issue,
> thanks for all explanations for far ;-)
So regression is on vhost "host14.example.com" right? And not
"fproxy.example.com"?
Cheers;
Yann.
On Mon, May 19, 2025 at 7:42 PM Yann Ylavic wrote:
>
> On Mon, May 19, 2025 at 5:47 PM Ruediger Pluem wrote:
> >
> > On 5/19/25 5:27 PM, Yann Ylavic wrote:
> > > On Mon, May 19, 2025 at 4:54 PM Stefan Eissing via dev
> > > wrote:
> > >>
&g
On Mon, May 19, 2025 at 5:47 PM Ruediger Pluem wrote:
>
> On 5/19/25 5:27 PM, Yann Ylavic wrote:
> > On Mon, May 19, 2025 at 4:54 PM Stefan Eissing via dev
> > wrote:
> >>
> >>> Am 19.05.2025 um 16:46 schrieb Yann Ylavic :
> >>>
> >&
On Mon, May 19, 2025 at 4:54 PM Stefan Eissing via dev
wrote:
>
> > Am 19.05.2025 um 16:46 schrieb Yann Ylavic :
> >
> >
> > Hm, r1912459 added this test to disable reuse for CONNECT connections
> > to ProxyRemote, because I thought that CONNECT requests were not
On Mon, May 19, 2025 at 4:05 PM Ruediger Pluem wrote:
>
>
>
> On 5/19/25 1:53 PM, jean-frederic clere wrote:
> > Hi,
> >
> > While investigating a customer case I note a regression with forward proxy.
> > While testing I have:
> > 2.4.57 finished in 3.05s, 3278.62 req/s, 743.70KB/s
> > 2.4.x fin
On Wed, Feb 12, 2025 at 12:38 PM Yann Ylavic wrote:
>
> However it seems that [4] will cause worker->s->is_address_reusable =
> 0 in [3] (i.e. disable DNS reuse altogether) which is not really
> expected, and would explain why the pool is cleared in
> connection_cleanu
On Wed, Feb 12, 2025 at 12:07 PM Yann Ylavic wrote:
>
> On Wed, Feb 12, 2025 at 11:16 AM jean-frederic clere
> wrote:
> >
> > According to my tests for some reasons ap_proxy_release_connection() now
> > does an apr_pool_clear() and was doing a connection_cleanup() b
On Wed, Feb 12, 2025 at 11:16 AM jean-frederic clere wrote:
>
> According to my tests for some reasons ap_proxy_release_connection() now
> does an apr_pool_clear() and was doing a connection_cleanup() before 2.4.58.
What does your ProxyPass/ProxyPassMatch look like?
AFAICT connection_cleanup() cl
On Fri, Feb 7, 2025 at 5:56 PM jean-frederic clere wrote:
>
> I have the above error on windows:
> +++
> [Fri Feb 07 08:46:33.110167 2025] [proxy:debug] [pid 7440:tid 1168]
> mod_proxy.c(1465): [client ::1:56280] AH01143: Running scheme balancer
> handler (attempt 0)
> [Fri Feb 07 08:46:33.110167
On Wed, Feb 5, 2025 at 5:15 PM Ruediger Pluem wrote:
>
>
>
> On 2/5/25 5:01 PM, Yann Ylavic wrote:
> > On Wed, Feb 5, 2025 at 9:13 AM Ruediger Pluem wrote:
> >>
> >> Just to draw a bit of attention to
> >> https://bz.apache.org/bugzilla/show_bug.
On Wed, Feb 5, 2025 at 9:13 AM Ruediger Pluem wrote:
>
> Just to draw a bit of attention to
> https://bz.apache.org/bugzilla/show_bug.cgi?id=69561
>
> Is it possible that we need to ensure that at least some of the init actions
> in ssl_init_Module in ssl_engine_init.c are only
> executed once b
On Mon, Jan 20, 2025 at 8:43 PM Jim Jagielski wrote:
>
> I would like to call a VOTE over the next few days to release
> this candidate tarball httpd-2.4.63 as 2.4.63:
[X] +1: It's not just good, it's good enough!
All tests pass on Debian 12/13.
Thanks Jim!
On Wed, Aug 7, 2024 at 11:44 AM Ruediger Pluem wrote:
>
> On 8/2/24 2:53 AM, yla...@apache.org wrote:
> >
> > --- httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c (original)
> > +++ httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c Fri Aug 2 00:53:53
> > 2024
>
> > @@ -93,20 +95,40 @@ static int
On Thu, Aug 8, 2024 at 11:45 AM Ruediger Pluem wrote:
>
> On 7/27/24 3:54 PM, yla...@apache.org wrote:
> >
> > --- httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c (original)
> > +++ httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c Sat Jul 27 13:54:08
> > 2024
> > @@ -133,7 +133,6 @@ static int p
On Wed, Sep 11, 2024 at 5:59 PM Yann Ylavic wrote:
>
> On Mon, Sep 9, 2024 at 12:20 PM Ruediger Pluem wrote:
> >
> > Looks like there is no further feedback on the below.
> > @Yann: Care to commit
> > https://bz.apache.org/bugzilla/attachment.cgi?id=39832 ?
&g
On Mon, Sep 9, 2024 at 12:20 PM Ruediger Pluem wrote:
>
> Looks like there is no further feedback on the below.
> @Yann: Care to commit https://bz.apache.org/bugzilla/attachment.cgi?id=39832 ?
> I would then commit my stuff below.
Done (r1920570).
I suppose we need a single backport proposal for
On Thu, Aug 8, 2024 at 10:19 AM Ruediger Pluem wrote:
Sorry for the late reply, I was quite busy at work$ back from vacations..
>
> On 7/17/24 10:50 PM, yla...@apache.org wrote:
> > --- httpd/httpd/trunk/modules/mappers/mod_rewrite.c (original)
> > +++ httpd/httpd/trunk/modules/mappers/mod_rewri
On Fri, Aug 2, 2024 at 3:26 PM Eric Covener wrote:
>
> On Fri, Aug 2, 2024 at 9:10 AM Yann Ylavic wrote:
> >
> > On Fri, Aug 2, 2024 at 1:06 PM Eric Covener wrote:
> > >
> > > > Yeah, if not under DocumentRoot I don't see how ProxyPass could wo
On Fri, Aug 2, 2024 at 3:10 PM Yann Ylavic wrote:
>
> On Fri, Aug 2, 2024 at 1:06 PM Eric Covener wrote:
> >
> > > Yeah, if not under DocumentRoot I don't see how ProxyPass could work,
> > > but SetHandler should since it's following the whole request
>
On Fri, Aug 2, 2024 at 1:06 PM Eric Covener wrote:
>
> > Yeah, if not under DocumentRoot I don't see how ProxyPass could work,
> > but SetHandler should since it's following the whole request
> > processing to resolve the filesystem r->filename?
>
> In the examples I am seeing spot-checking google
On Fri, Aug 2, 2024 at 11:33 AM Yann Ylavic wrote:
>
> On Fri, Aug 2, 2024 at 6:02 AM Eric Covener wrote:
> >
> > On Thu, Aug 1, 2024 at 9:22 PM Yann Ylavic wrote:
> > > >
> > > > For this how about this attached patch?
> > > > With it I
On Fri, Aug 2, 2024 at 6:02 AM Eric Covener wrote:
>
> On Thu, Aug 1, 2024 at 9:22 PM Yann Ylavic wrote:
> > >
> > > For this how about this attached patch?
> > > With it I can get the correct env vars (I think), and since we'd not
> > > send a &quo
On Fri, Aug 2, 2024 at 5:22 AM Eric Covener wrote:
>
> On Thu, Aug 1, 2024 at 9:12 PM Yann Ylavic wrote:
> >
> > On Fri, Aug 2, 2024 at 12:18 AM Yann Ylavic wrote:
> > >
> > > So we probably should keep encoding r->filename with ProxyPass, and
> > &
On Fri, Aug 2, 2024 at 3:12 AM Yann Ylavic wrote:
>
> On Fri, Aug 2, 2024 at 12:18 AM Yann Ylavic wrote:
> >
> > So we probably should keep encoding r->filename with ProxyPass, and
> > come back to my previous patch which skipped it only for SetHandler?
> > Po
On Fri, Aug 2, 2024 at 12:18 AM Yann Ylavic wrote:
>
> So we probably should keep encoding r->filename with ProxyPass, and
> come back to my previous patch which skipped it only for SetHandler?
> Possibly FCGI_MAY_BE_FPM() only too because for "ProxyFCGIBackendType
> GEN
On Thu, Aug 1, 2024 at 9:53 PM Eric Covener wrote:
>
> On Thu, Aug 1, 2024 at 2:47 PM Yann Ylavic wrote:
> >
> > On Thu, Aug 1, 2024 at 7:57 PM Eric Covener wrote:
> > >
> > > On Thu, Aug 1, 2024 at 1:37 PM Yann Ylavic wrote:
> > > >
> >
On Thu, Aug 1, 2024 at 7:57 PM Eric Covener wrote:
>
> On Thu, Aug 1, 2024 at 1:37 PM Yann Ylavic wrote:
> >
> > On Thu, Aug 1, 2024 at 5:51 PM Eric Covener wrote:
> > >
> > > But does it leave the splitting problem with decoded %3F?
> >
> >
On Thu, Aug 1, 2024 at 5:51 PM Eric Covener wrote:
>
> But does it leave the splitting problem with decoded %3F?
Yeah but I'm not sure that it's _our_ problem, a "proxy:" r->filename
does never contain the query-string in the first place, so any '?' in
there (hence in SCRIPT_FILENAME) is part of
On Wed, Jul 31, 2024 at 7:34 PM Eric Covener wrote:
>
> On Tue, Jul 23, 2024 at 5:35 AM Yann Ylavic wrote:
> >
> > On Wed, Jul 17, 2024 at 6:22 PM wrote:
> > >
> > > https://bz.apache.org/bugzilla/show_bug.cgi?id=69203
> > >
> > > --- Com
On Wed, Jul 31, 2024 at 6:57 PM wrote:
>
> https://bz.apache.org/bugzilla/show_bug.cgi?id=69235
>
> --- Comment #2 from Yann Ylavic ---
> Created attachment 39832
> --> https://bz.apache.org/bugzilla/attachment.cgi?id=39832&action=edit
> mod_proxy fixup after mod_
On Fri, Jul 26, 2024 at 6:10 PM Joe Orton wrote:
>
> On Fri, Jul 26, 2024 at 03:52:40PM -, yla...@apache.org wrote:
> > Author: ylavic
> > Date: Fri Jul 26 15:52:40 2024
> > New Revision: 1919534
> >
> > URL: http://svn.apache.org/viewvc?rev=1919534&view=rev
> > Log:
> > Is that what's wrong i
On Wed, Jul 17, 2024 at 6:22 PM wrote:
>
> https://bz.apache.org/bugzilla/show_bug.cgi?id=69203
>
> --- Comment #6 from Yann Ylavic ---
> Created attachment 39817
> --> https://bz.apache.org/bugzilla/attachment.cgi?id=39817&action=edit
> Proxy FCGI nocanon from Set
On Mon, Jul 15, 2024 at 2:14 PM Eric Covener wrote:
>
> I would like to call a VOTE over the next few days to release
> this candidate tarball httpd-2.4.62-rc1 as 2.4.62:
[X] +1: It's not just good, it's good enough!
Tested on Debian stable and testing/sid, all passes.
Sigs/checksums OK.
Thanks
On Thu, Jul 11, 2024 at 4:19 PM wrote:
> --- httpd/httpd/branches/2.4.x/STATUS (original)
> +++ httpd/httpd/branches/2.4.x/STATUS Thu Jul 11 14:19:08 2024
> @@ -166,6 +166,34 @@ PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
> +
> + *) mod_http2: sync with github module. Add async handling
> + on n
On Thu, Jul 11, 2024 at 3:59 PM wrote:
>
> Author: ylavic
> Date: Thu Jul 11 13:58:47 2024
> New Revision: 1919139
>
> URL: http://svn.apache.org/viewvc?rev=1919139&view=rev
> Log:
> Backported.
>
> - *) mod_proxy: Backport for PRs 69160 and 69168
> - Trunk version of patch:
> -https:
On Fri, Jul 5, 2024 at 5:59 PM Yann Ylavic wrote:
>
> On Fri, Jul 5, 2024 at 5:08 PM Ruediger Pluem wrote:
> >
> > On 7/5/24 4:09 PM, Stefan Eissing via dev wrote:
> > >
> > > The patches look good to me. I have not tested them as I have no old
> > &
On Fri, Jul 5, 2024 at 5:08 PM Ruediger Pluem wrote:
>
> On 7/5/24 4:09 PM, Stefan Eissing via dev wrote:
> >
> >
> >> Am 05.07.2024 um 15:44 schrieb Ruediger Pluem :
> >>
> >>
> >>
> >> On 7/5/24 3:40 PM, Yann Ylavic
On Fri, Jul 5, 2024 at 3:35 PM Yann Ylavic wrote:
>
> On Fri, Jul 5, 2024 at 3:05 PM Ruediger Pluem wrote:
> >
> > >>>> md_crypt.c: In function 'md_cert_get_ct_scts':
> > >>>> md_crypt.c:2071:5: error: unknown type name 'SCT'
On Fri, Jul 5, 2024 at 3:05 PM Ruediger Pluem wrote:
>
> md_crypt.c: In function 'md_cert_get_ct_scts':
> md_crypt.c:2071:5: error: unknown type name 'SCT'
> SCT *sct_handle;
>
> This one is caused by r1918195 in >= 2.4.60. Before r1918195 OPENSSL_NO_CT
> was defined when opens
On Fri, Jul 5, 2024 at 3:16 PM Yann Ylavic wrote:
>
> On Fri, Jul 5, 2024 at 3:05 PM Ruediger Pluem wrote:
> >
> >
> >
> > On 7/5/24 2:14 PM, Ruediger Pluem wrote:
> > >
> > >
> > > On 7/5/24 2:11 PM, Ruediger Pluem wrote:
> > &
On Fri, Jul 5, 2024 at 3:05 PM Ruediger Pluem wrote:
>
>
>
> On 7/5/24 2:14 PM, Ruediger Pluem wrote:
> >
> >
> > On 7/5/24 2:11 PM, Ruediger Pluem wrote:
> >>
> >>
> >> On 7/5/24 2:04 PM, Stefan Eissing via dev wrote:
> >>>
> >>>
> Am 05.07.2024 um 13:51 schrieb Ruediger Pluem :
>
> >>>
On Wed, Jul 3, 2024 at 4:40 PM Ruediger Pluem wrote:
>
> On 7/3/24 3:23 PM, Yann Ylavic wrote:
> > On Wed, Jul 3, 2024 at 2:34 PM Ruediger Pluem wrote:
> >>
> >> Thanks for the intense review. I hope I captured all stuff in the below.
> >
> > Thanks for
On Wed, Jul 3, 2024 at 4:40 PM Ruediger Pluem wrote:
>
> On 7/3/24 3:23 PM, Yann Ylavic wrote:
> > On Wed, Jul 3, 2024 at 2:34 PM Ruediger Pluem wrote:
> >>
> >> Thanks for the intense review. I hope I captured all stuff in the below.
> >
> > Thanks for
On Wed, Jul 3, 2024 at 2:34 PM Ruediger Pluem wrote:
>
> Thanks for the intense review. I hope I captured all stuff in the below.
Thanks for working on this.
> I intentionally left the 'len' parameter of ssl_io_data_dump an apr_size_t in
> case we ever get to the conclusion that we want to
> ma
On Wed, Jul 3, 2024 at 11:01 AM Yann Ylavic wrote:
>
> On Wed, Jul 3, 2024 at 10:57 AM Yann Ylavic wrote:
> >
> > On Wed, Jul 3, 2024 at 8:58 AM Ruediger Pluem wrote:
> > >
> > > On 7/3/24 2:59 AM, Yann Ylavic wrote:
> > > > On Tue, Jul 2,
On Wed, Jul 3, 2024 at 10:57 AM Yann Ylavic wrote:
>
> On Wed, Jul 3, 2024 at 8:58 AM Ruediger Pluem wrote:
> >
> > On 7/3/24 2:59 AM, Yann Ylavic wrote:
> > > On Tue, Jul 2, 2024 at 10:57 AM Ruediger Pluem wrote:
> > >>
> > >> Updat
On Wed, Jul 3, 2024 at 8:58 AM Ruediger Pluem wrote:
>
> On 7/3/24 2:59 AM, Yann Ylavic wrote:
> > On Tue, Jul 2, 2024 at 10:57 AM Ruediger Pluem wrote:
> >>
> >> Updated patch.
[]
> >> const char *dump = "";
> >
On Tue, Jul 2, 2024 at 10:57 AM Ruediger Pluem wrote:
>
> On 7/1/24 3:01 PM, Ruediger Pluem wrote:
> >
> >
> > On 6/27/24 3:48 PM, Ruediger Pluem wrote:
> >>
> >>
> >> On 6/27/24 12:47 PM, Yann Ylavic wrote:
> >>> On Thu, Jun 27, 20
On Tue, Jul 2, 2024 at 3:45 PM Eric Covener wrote:
>
> Hi all,
>
> Please find below the proposed release tarball and signatures:
>
> https://dist.apache.org/repos/dist/dev/httpd/
>
> === Different from template ===
> I would like to call an expedited VOTE (due to regression in 2.4.60)
> over the
On Thu, Jun 27, 2024 at 12:38 PM Yann Ylavic wrote:
>
> On Thu, Jun 27, 2024 at 12:07 PM Ruediger Pluem wrote:
> >
> > How about the below? I am yet undecided if I should follow the below
> > approach to have
> > two completely separate callbacks depending
On Thu, Jun 27, 2024 at 12:07 PM Ruediger Pluem wrote:
>
> How about the below? I am yet undecided if I should follow the below approach
> to have
> two completely separate callbacks depending on the OpenSSL version or one
> with a lot of
> #If statements in it, but as much shared code as possib
On Wed, Jun 26, 2024 at 7:10 PM Eric Covener wrote:
>
> I would like to call a VOTE over the next few days to release
> this candidate tarball httpd-2.4.60-rc4 as 2.4.60:
[X] +1: It's not just good, it's good enough!
Tested on Debian stable and testing/sid, all passes.
Sigs/checksums OK too.
Gr
On Wed, Jun 26, 2024 at 12:09 PM wrote:
>
> --- httpd/httpd/trunk/modules/mappers/mod_rewrite.c (original)
> +++ httpd/httpd/trunk/modules/mappers/mod_rewrite.c Wed Jun 26 10:09:29 2024
> @@ -4413,10 +4410,15 @@ static rule_return_type apply_rewrite_ru
> && !is_absolute_path(newuri)
>
On Wed, Jun 26, 2024 at 10:28 AM Ruediger Pluem wrote:
>
> On 3/19/23 10:30 PM, yla...@apache.org wrote:
> >
> > --- httpd/httpd/trunk/modules/ssl/ssl_engine_io.c (original)
> > +++ httpd/httpd/trunk/modules/ssl/ssl_engine_io.c Sun Mar 19 21:30:47 2023
>
> > @@ -2402,7 +2403,7 @@ long ssl_io_data_
On Wed, Jun 26, 2024 at 9:05 AM Ruediger Pluem wrote:
>
> On 6/26/24 1:49 AM, yla...@apache.org wrote:
> >
> > --- httpd/httpd/trunk/modules/proxy/mod_proxy.c (original)
> > +++ httpd/httpd/trunk/modules/proxy/mod_proxy.c Tue Jun 25 23:49:09 2024
>
> > @@ -1319,22 +1320,29 @@ static int proxy_hand
On Wed, Jun 26, 2024 at 12:02 AM Helmut K. C. Tessarek
wrote:
>
> I tried with rc2, since rc3 is not available yet.
>
> Same issue.
Should be fixed by
https://github.com/apache/httpd/commit/6937b985ae112de0ad60f12a3cb522b608a4d501.diff
Regards;
Yann.
On Wed, Jun 26, 2024 at 2:02 AM Yann Ylavic wrote:
>
> On Tue, Jun 25, 2024 at 7:29 PM wrote:
> >
> > Author: covener
> > Date: Tue Jun 25 17:29:06 2024
> > New Revision: 1918606
> >
> > URL: http://svn.apache.org/viewvc?rev=1918606&view=rev
>
On Tue, Jun 25, 2024 at 7:29 PM wrote:
>
> Author: covener
> Date: Tue Jun 25 17:29:06 2024
> New Revision: 1918606
>
> URL: http://svn.apache.org/viewvc?rev=1918606&view=rev
> Log:
> validate hostname
Seems this broke something in the http2 tests. Will have a look tomorrow.
On Wed, Jun 26, 2024 at 1:17 AM Eric Covener wrote:
>
> On Tue, Jun 25, 2024 at 7:03 PM Yann Ylavic wrote:
> >
> > On Wed, Jun 26, 2024 at 12:37 AM Eric Covener wrote:
> > >
> > > > The attached might work, currently testing but sending early if you
>
On Wed, Jun 26, 2024 at 12:37 AM Eric Covener wrote:
>
> > The attached might work, currently testing but sending early if you
> > want to try too.
>
> looks like proxy: is stripped off after the new call and needs to be
> added back in?
Yeah, the new call to ap_proxy_fixup_uds_filename() should
On Tue, Jun 25, 2024 at 11:35 PM Eric Covener wrote:
>
> On Tue, Jun 25, 2024 at 5:22 PM Eric Covener wrote:
> >
> > On Tue, Jun 25, 2024 at 5:06 PM Eric Covener wrote:
> > >
> > > On Tue, Jun 25, 2024 at 4:35 PM Helmut K. C. Tessarek
> > > wrote:
> > > >
> > > > On 2024-06-25 02:53, Ruediger P
On Tue, Jun 25, 2024 at 2:50 PM Eric Covener wrote:
>
> - whether backing out
> https://github.com/apache/httpd/commit/9494aa8d52e3c263bc0413b77ac8a73b0d524388.diff
> from the candidate helps?
I'm not sure r1918553 made it to rc1, did it?
On Wed, Jun 5, 2024 at 5:24 PM Eric Covener wrote:
>
> Please make sure your backport proposals/votes are in.
Fix for addressTTL (PR 454) is missing one vote, would be nice to fix
it in 2.4.60.
Thanks!
On Wed, Jun 19, 2024 at 4:34 PM Yann Ylavic wrote:
>
> On Wed, Jun 19, 2024 at 4:23 PM Joe Orton wrote:
> >
> > On Wed, Jun 19, 2024 at 03:41:06PM +0200, Yann Ylavic wrote:
> > > Done in PR 454, will update STATUS too.
> >
> > In the path where keep_addr_a
On Wed, Jun 19, 2024 at 4:23 PM Joe Orton wrote:
>
> On Wed, Jun 19, 2024 at 03:41:06PM +0200, Yann Ylavic wrote:
> > Done in PR 454, will update STATUS too.
>
> In the path where keep_addr_alive and keep_conn_alive are both false,
> conn_cleanup(conn) is run, which sets conn
On Wed, Jun 19, 2024 at 2:52 PM Joe Orton wrote:
>
> On Wed, Jun 19, 2024 at 02:04:20PM +0200, Yann Ylavic wrote:
> > On Wed, Jun 19, 2024 at 1:00 PM Ruediger Pluem wrote:
> > > As far as I read the code it does not.
> > >
> >
On Wed, Jun 19, 2024 at 2:49 PM Ruediger Pluem wrote:
>
> On 6/19/24 2:04 PM, Yann Ylavic wrote:
>
> > On Wed, Jun 19, 2024 at 1:00 PM Ruediger Pluem wrote:
> >>
> >> As far as I read the code it does not.
> >>
> >> https://github.com/apach
On Wed, Jun 19, 2024 at 1:00 PM Ruediger Pluem wrote:
>
> On 6/19/24 12:00 PM, Yann Ylavic wrote:
> > On Wed, Jun 19, 2024 at 9:07 AM Ruediger Pluem wrote:
> >>
> >> On 6/18/24 4:20 PM, yla...@apache.org wrote:
> >>>
> >>> +/*
On Wed, Jun 19, 2024 at 9:07 AM Ruediger Pluem wrote:
>
> On 6/18/24 4:20 PM, yla...@apache.org wrote:
> >
> > +/* Release the old conn address */
> > +if (conn->address) {
> > +/* conn->address->addr cannot be released while it's used
> > by
> > +
On Tue, May 28, 2024 at 4:06 PM Stefan Eissing via dev
wrote:
>
>
>
> > Am 28.05.2024 um 15:45 schrieb Yann Ylavic :
> >
> > On Tue, May 28, 2024 at 12:47 PM Stefan Eissing via dev
> > wrote:
> >>
> >>> Am 27.05.2024 um 14:08 schrieb Yann Yla
On Tue, May 28, 2024 at 12:47 PM Stefan Eissing via dev
wrote:
>
> > Am 27.05.2024 um 14:08 schrieb Yann Ylavic :
> >
> > Per our discussion the other day, if you want to avoid c1 connections
> > to be killed by mpm_event on high load in this case, I think you can
>
On Mon, May 27, 2024 at 1:04 PM wrote:
>
> Author: icing
> Date: Mon May 27 11:04:52 2024
> New Revision: 1918003
>
> URL: http://svn.apache.org/viewvc?rev=1918003&view=rev
> Log:
> *) mod_http2: sync with module's github.
> - on newer HTTPD versions, return connection monitoring
> to t
On Tue, May 14, 2024 at 12:21 PM Stefan Eissing via dev
wrote:
>
> Tried your PR and it works nicely without any changes to current mod_h2.
Great, thanks for testing!
With the current mod_h2 I think the connections returned to mpm_event
use the KeepAliveTimeout rather than Timeout. Enough for th
On Mon, May 13, 2024 at 9:02 PM Yann Ylavic wrote:
>
> On Mon, May 13, 2024 at 6:31 PM Stefan Eissing wrote:
> >
> > > Am 13.05.2024 um 17:41 schrieb Yann Ylavic :
> > >
> > > On Mon, May 13, 2024 at 1:32 PM Stefan Eissing
> > >>
> > >
On Mon, May 13, 2024 at 6:31 PM Stefan Eissing wrote:
>
> > Am 13.05.2024 um 17:41 schrieb Yann Ylavic :
> >
> > On Mon, May 13, 2024 at 1:32 PM Stefan Eissing
> >>
> >> With the change in PR 280, we return on being flow blocked. The
> >> response
On Mon, May 13, 2024 at 1:32 PM Stefan Eissing via dev
wrote:
>
> I have merged https://github.com/icing/mod_h2/pull/280 to the mod-h2 on
> github. With mpm_event, this will return HTTP/2 connections more often to the
> mpm, thus freeing a worker.
>
> While this sounds good, I am not sure this i
On Thu, Apr 18, 2024 at 3:21 PM Joe Orton wrote:
>
> On Thu, Apr 18, 2024 at 09:40:21AM +0100, Graham Leggett via dev wrote:
> > Hi all,
> >
> > The attached patch is a current work in progress patch for httpd-trunk to
> > use the new apr_ldap API that just landing in APR.
> >
> > The highlights:
On Fri, Apr 12, 2024 at 3:02 PM Ruediger Pluem wrote:
>
> On 4/12/24 12:35 PM, yla...@apache.org wrote:
> > Author: ylavic
> > Date: Fri Apr 12 10:35:10 2024
> > New Revision: 1916925
> >
> > URL: http://svn.apache.org/viewvc?rev=1916925&view=rev
> > Log:
> > mpm_event: Simplify pollset "good meth
On Sat, Apr 6, 2024 at 10:46 AM jean-frederic clere wrote:
>
> It seems pthread_kill(t, 0) returns 0 even the thread t has exited...
> older version of fedora will return 3 (I have tried fc28)
>
> The small example (taken from the internet) seems to behave like httpd
> reporting running threads th
On Sun, Apr 7, 2024 at 2:16 PM Rainer Jung wrote:
>
> Am 07.04.24 um 09:42 schrieb jean-frederic clere:
> > On 4/6/24 20:02, Rainer Jung wrote:
> >
> >> When you say Yann's patch helps, it means especially there are not
> >> more SIGTERM messages in the logs resp. no more teardown checks failing?
On Sat, Apr 6, 2024 at 10:46 AM jean-frederic clere wrote:
>
> On 4/5/24 07:55, Ruediger Pluem wrote:
> >
> > Are you able to provide a stacktrace of the hanging process (thread apply
> > all bt full)?
>
> It seems pthread_kill(t, 0) returns 0 even the thread t has exited...
> older version of fe
On Thu, Apr 4, 2024 at 12:52 PM Steffen Land wrote:
>
> -1
> Get an error:
>
> Error C2065 'DAV_WALKTYPE_TOLERANT': undeclared identifier mod_dav_fs
> C:\VS17\Win32\httpd-2.4\modules\dav\fs\repos.c 1599
Are you compiling with an old "mod_dav.h" somewhere in the -I[nclude] path?
Becaus
On Wed, Apr 3, 2024 at 2:26 PM Eric Covener wrote:
>
> I would like to call a SHORTENED VOTE to release
> this candidate tarball httpd-2.4.59-rc1 as 2.4.59:
[X] +1: It's not just good, it's good enough!
All good from my testing on debian(s).
Thanks Eric!
On Tue, Mar 12, 2024 at 4:08 PM Eric Covener wrote:
>
> below + POD wakeup
>
> Did not force the path yet where the listener is started (or fold in
> the scoreboard change )
+1, maybe ap_queue_term() rather than ap_queue_interrupt_all().
On Tue, Mar 12, 2024 at 3:30 PM Eric Covener wrote:
>
> On Tue, Mar 12, 2024 at 10:19 AM Yann Ylavic wrote:
> >
> > On Tue, Mar 12, 2024 at 3:03 PM Eric Covener wrote:
> > >
> > > On Tue, Mar 12, 2024 at 8:48 AM Yann Ylavic wrote:
> > >
On Tue, Mar 12, 2024 at 3:03 PM Eric Covener wrote:
>
> On Tue, Mar 12, 2024 at 8:48 AM Yann Ylavic wrote:
> >
> > Maybe it could be:
> > if (threads_created) {
>
> not listener_started?
>
> threads_started>0 could just mean we had no scoreboar
On Tue, Mar 12, 2024 at 1:46 PM Yann Ylavic wrote:
>
> Maybe it could be:
We should probably prevent the listener from starting too, like:
> if (threads_created) {
> resource_shortage = 1;
> signal_threads(ST_GRACEFUL);
listener_started = 1; /* do
On Tue, Mar 12, 2024 at 1:06 PM Eric Covener wrote:
>
> On Mon, Mar 11, 2024 at 8:28 PM wrote:
> >
> > Author: covener
> > Date: Tue Mar 12 00:28:34 2024
> > New Revision: 1916243
> >
> > URL: http://svn.apache.org/viewvc?rev=1916243&view=rev
> > Log:
> > use graceful exit if lister started
> >
>
On Fri, Mar 1, 2024 at 2:12 PM Joe Orton wrote:
>
> On Fri, Mar 01, 2024 at 01:52:15PM +0100, Yann Ylavic wrote:
> > On Fri, Mar 1, 2024 at 1:42 PM Yann Ylavic wrote:
> > >
> > > On Fri, Mar 1, 2024 at 1:24 PM Joe Orton wrote:
> > > >
> > > &
On Fri, Mar 1, 2024 at 1:42 PM Yann Ylavic wrote:
>
> On Fri, Mar 1, 2024 at 1:24 PM Joe Orton wrote:
> >
> > Also - I guess the note about *not* accepting PKCS#8 format keys in
> > https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslproxymachinecertificatefi
On Fri, Mar 1, 2024 at 1:42 PM Yann Ylavic wrote:
>
> On Fri, Mar 1, 2024 at 1:24 PM Joe Orton wrote:
> >
> > Do you still want that
> > TestSSLCA.pm change merged?
>
> I think it can be useful for those who test httpd with openssl1 still
> (not mainta
On Fri, Mar 1, 2024 at 1:24 PM Joe Orton wrote:
>
> On Fri, Mar 01, 2024 at 12:59:10PM +0100, Yann Ylavic wrote:
> > On Fri, Mar 1, 2024 at 11:15 AM wrote:
> > >
> > > Author: jorton
> > > Date: Fri Mar 1 10:15:13 2024
> > > New Revision: 19160
On Fri, Mar 1, 2024 at 12:59 PM Yann Ylavic wrote:
>
> On Fri, Mar 1, 2024 at 11:15 AM wrote:
> >
> > Author: jorton
> > Date: Fri Mar 1 10:15:13 2024
> > New Revision: 1916068
> >
> > URL: http://svn.apache.org/viewvc?rev=1916068&view=rev
>
On Fri, Mar 1, 2024 at 11:15 AM wrote:
>
> Author: jorton
> Date: Fri Mar 1 10:15:13 2024
> New Revision: 1916068
>
> URL: http://svn.apache.org/viewvc?rev=1916068&view=rev
> Log:
> CI: add OpenSSL 3.2, test OpenSSL 3.x using Apache::Test
> trunk to pick up r1916067.
I had to modify Apache-Test
1 - 100 of 1104 matches
Mail list logo
