Re: child exit on self-proxy

n see that socket 7f95ba07b4b0 is closed twice. I attach my log and v5 patch (which is Yann's plus some extra log around closing). error_log Description: Binary data event_ka_no_lingerv5.diff Description: Binary data > Am 13.07.2021 um 16:03 schrieb Stefan Eissing : > > Wait a minut

Re: child exit on self-proxy

Wait a minute...need to confirm that I am not lying and used an older patch version... > Am 13.07.2021 um 16:01 schrieb Stefan Eissing : > > Found one condition where the assertion failure happens. The test case I have > does this: > > sock = socket.create_connection((host,

Re: child exit on self-proxy

ylib 0x7fff2030d443 thread_start + 15 - Stefan > Am 13.07.2021 um 12:39 schrieb Stefan Eissing : > > Coming back to this: I vote for applying this to trunk. On a fresh setup, I > do not see and assert failures in my test. > > - Stefan > >> Am 08.07.2021 um

Re: child exit on self-proxy

Coming back to this: I vote for applying this to trunk. On a fresh setup, I do not see and assert failures in my test. - Stefan > Am 08.07.2021 um 20:17 schrieb Yann Ylavic : > > On Thu, Jul 8, 2021 at 4:21 PM Stefan Eissing > wrote: >> >> I see many of those: >&g

Re: ap_proxy_acquire_connection crash? (was Re: Broken: apache/httpd#1739 (trunk - f087735))

> Am 12.07.2021 um 12:34 schrieb Yann Ylavic : > > On Mon, Jul 12, 2021 at 10:01 AM Joe Orton wrote: >> >> Thread 1 (Thread 0x7f101cff1700 (LWP 3534)): >> 3622#0 ap_proxy_acquire_connection >> (proxy_function=proxy_function@entry=0x7f105467de9f "http", >> conn=conn@entry=0x7f101cff0a88, wo

Re: ap_proxy_acquire_connection crash? (was Re: Broken: apache/httpd#1739 (trunk - f087735))

> Am 12.07.2021 um 11:07 schrieb Yann Ylavic : > > On Mon, Jul 12, 2021 at 10:13 AM Stefan Eissing > wrote: >> >> Is this the "worker->cp" being NULL? > > Is there a discussion about this already Stefan? I have not analyzed all possible paths

Re: ap_proxy_acquire_connection crash? (was Re: Broken: apache/httpd#1739 (trunk - f087735))

> Am 12.07.2021 um 10:00 schrieb Joe Orton : > > On Fri, Jul 09, 2021 at 06:00:26PM +, Travis CI wrote: >> Build Update for apache/httpd >> - >> >> Build: #1739 >> Status: Broken >> >> Duration: 21 mins and 57 secs >> Commit: f087735 (trunk) >> Author:

Re: child exit on self-proxy

Rarely seeing a close_socket_nonblocking + 83 (event.c:566) assertion failure. :-/ > Am 09.07.2021 um 09:38 schrieb Stefan Eissing : > > > >> Am 08.07.2021 um 20:17 schrieb Yann Ylavic : >> >> On Thu, Jul 8, 2021 at 4:21 PM Stefan Eissing >> wrote: &g

Re: child exit on self-proxy

> Am 08.07.2021 um 20:17 schrieb Yann Ylavic : > > On Thu, Jul 8, 2021 at 4:21 PM Stefan Eissing > wrote: >> >> I see many of those: >> [Thu Jul 08 14:16:55.301670 2021] [mpm_event:error] [pid 81101:tid >> 123145411510272] (9)Bad file descriptor:

Re: child exit on self-proxy

*stands in the pentagram of blood drawn by Yann* "I'll do thy bidding and report back!" > Am 08.07.2021 um 20:17 schrieb Yann Ylavic : > > On Thu, Jul 8, 2021 at 4:21 PM Stefan Eissing > wrote: >> >> I see many of those: >> [Thu Jul 08 14:16:55.

Re: child exit on self-proxy

: kill_connection_ex(cs, from); and event.c#837: close_socket_nonblocking_ex(cs->pfd.desc.s, from); Patch attached. event_ka_no_lingerv3.diff Description: Binary data > Am 08.07.2021 um 15:46 schrieb Yann Ylavic : > > On Thu, Jul 8, 2021 at 3:35 PM Stefan Eissing > wrote: >>>

Re: child exit on self-proxy

> Am 08.07.2021 um 15:33 schrieb Yann Ylavic : > > On Thu, Jul 8, 2021 at 2:55 PM Stefan Eissing > wrote: >> >> This seems to be it! Yann strikes again! And I learned something...\o/ > > Thanks Stefan :) > >> >> I needed to make small twea

Re: child exit on self-proxy

> Am 08.07.2021 um 14:14 schrieb Yann Ylavic : > > On Thu, Jul 8, 2021 at 11:47 AM Stefan Eissing > wrote: >> >> Some day, I knew I had to learn more about mpm_event. =) >> >> Adding more DEBUGs, I see in the example below that 2 connections were >&g

Re: child exit on self-proxy

tions event_debugv3.diff Description: Binary data > Am 07.07.2021 um 18:49 schrieb Stefan Eissing : > > > >> Am 07.07.2021 um 18:34 schrieb Yann Ylavic : >> >> Does this attached patch help? This is to verify an hypothesis where >> killed keepalive connections are sti

Re: child exit on self-proxy

70007)The timeout specified has expired: AH: pollset returned listener_may_exit=1 connection_count=1 [Wed Jul 07 16:48:08.443149 2021] [mpm_event:trace1] [pid 55134:tid 123145362530304] event.c(1809): All workers are busy or dying, will close 0 keep-alive connections > > On Wed, J

Re: child exit on self-proxy

123145502474240] event.c(1809): All workers are busy or dying, will close 0 keep-alive connections event_debugv2.diff Description: Binary data Btw. I opened a bottle of nice wine - this is entertaining. ;-) - Stefan > Am 07.07.2021 um 17:48 schrieb Yann Ylavic : > > On Wed, Jul 7, 2021 at 5:45

Re: child exit on self-proxy

> Am 07.07.2021 um 17:39 schrieb Ruediger Pluem : > > > > On 7/7/21 5:25 PM, Stefan Eissing wrote: >> In order to reproduce the logs I see on this weird behaviour, I'll attach >> the patch I made: >> >> >> >> >> With this,

Re: child exit on self-proxy

sy or dying, will close 0 keep-alive connections Which says (to my eyes) that the pollset_wakeup happened, but the listener saw "listener_may_exit == 0". Is the volatile maybe not enough? > Am 07.07.2021 um 16:56 schrieb Stefan Eissing : > > > >> Am 07.07.

Re: child exit on self-proxy

> Am 07.07.2021 um 13:51 schrieb Yann Ylavic : > > On Wed, Jul 7, 2021 at 12:16 PM Stefan Eissing > wrote: >> >> I added a TRACE1 log in event.c before/after join_workers (line 2921) and >> see: >> >> [Wed Jul 07 10:06:03.144044 2021] [mpm_e

Re: child exit on self-proxy

Was busy on other things. Will try to get answers... > Am 07.07.2021 um 13:51 schrieb Yann Ylavic : > > On Wed, Jul 7, 2021 at 12:16 PM Stefan Eissing > wrote: >> >> I added a TRACE1 log in event.c before/after join_workers (line 2921) and >> see: >>

Re: child exit on self-proxy

> Am 07.07.2021 um 11:49 schrieb Ruediger Pluem : > > > > On 7/7/21 11:45 AM, Stefan Eissing wrote: >> In my h2 test suite, I do a setup where I use proxy configs against the >> server itself. We seem to have a problem performing a clean child exit with >&g

child exit on self-proxy

In my h2 test suite, I do a setup where I use proxy configs against the server itself. We seem to have a problem performing a clean child exit with that. Test in 2.4.48 and trunk: - run tests with several graceful restarts - no proxied request, clean exit - with proxied requests AH00045: child

Re: backend connections life times

certain content types, but that would not solve slow responsiveness. - Stefan > Am 01.07.2021 um 16:06 schrieb Stefan Eissing : > > > >> Am 01.07.2021 um 14:16 schrieb Yann Ylavic : >> >> On Thu, Jul 1, 2021 at 10:15 AM Stefan Eissing >> wrote: &

Re: backend connections life times

> Am 01.07.2021 um 14:16 schrieb Yann Ylavic : > > On Thu, Jul 1, 2021 at 10:15 AM Stefan Eissing > wrote: >> >>> Am 30.06.2021 um 18:01 schrieb Eric Covener : >>> >>> On Wed, Jun 30, 2021 at 11:46 AM Stefan Eissing >>> wrote:

Re: backend connections life times

> Am 30.06.2021 um 18:01 schrieb Eric Covener : > > On Wed, Jun 30, 2021 at 11:46 AM Stefan Eissing > wrote: >> >> It looks like we stumbled upon an issue in >> https://bz.apache.org/bugzilla/show_bug.cgi?id=65402 which concerns the life >> times of ou

backend connections life times

It looks like we stumbled upon an issue in https://bz.apache.org/bugzilla/show_bug.cgi?id=65402 which concerns the life times of our backend connections. When a frontend connection causes a backend request and drops, our backend connection only notifies the loss when it attempts to pass some da

ssl coalescing filter too aggressive?

Could someone with understanding of the mod_ssl output filters have a look at: https://bz.apache.org/bugzilla/show_bug.cgi?id=65402 It looks as if HTTP/2 frames are buffered. The browser sees a TimeToFirstByte of 12 seconds, but the server logs show that the frame data was put into the connecti

Re: Late(r) stop of children processes on restart

Can comment really on the diff, but totally agree on the goal to minimize the unresponsive time and make graceful less disruptive. So +1 for that. > Am 28.06.2021 um 16:25 schrieb Yann Ylavic : > > When the MPM event/worker is restarting, it first signals the > children's processes to stop (via

Re: mpm state changes

My PR with the changes supplied by Yann, for review: https://github.com/apache/httpd/pull/199 Cheers, Stefan

Re: mpm state changes

> Am 28.06.2021 um 11:18 schrieb Yann Ylavic : > > On Mon, Jun 28, 2021 at 10:28 AM Stefan Eissing > wrote: >> >> what do you think about adding a hook for MPMQ state changes? >> >> AP_MPMQ_STARTING -> AP_MPMQ_RUNNING -> AP_MPMQ_STOPPING > >

mpm state changes

Hi, what do you think about adding a hook for MPMQ state changes? AP_MPMQ_STARTING -> AP_MPMQ_RUNNING -> AP_MPMQ_STOPPING Background: several module monitor the state to abort a loop early to not delay a child exit unnecessarily. However there seems to be no notification mechanism available (o

mod-http2 workers dynamic

I am considering a change to mod_http2 that makes the h2 workers dynamic again: https://github.com/icing/mod_h2/pull/215 There is now some load test in that repository which I used to check the changes. You can run the interesting one as > make test # make sure test env is setup > python3 test

Re: Security policy on Github

> Am 25.06.2021 um 09:15 schrieb Ruediger Pluem : > > I would like to suggest that we fill a very basic document that shows on > Github as our security policy. > Below my proposal for a SECURITY.md : > > > === > # Security Polic

AP_MPMQ_STOPPING

Am I correct in my reading that there is not hook for being notified about AP_MPMQ_STOPPING? Background: I am looking for the right approach to shutdown all idle h2 workers on a graceful right away, independent of remaining request processing in other protocols. - Stefan

Re: svn commit: r1890693 - in /httpd/httpd/trunk: changes-entries/ssl_alpn_outgoing.txt modules/ssl/ssl_engine_io.c

> Am 11.06.2021 um 12:58 schrieb Yann Ylavic : > > On Fri, Jun 11, 2021 at 12:46 PM wrote: >> >> Author: icing >> Date: Fri Jun 11 10:45:25 2021 >> New Revision: 1890693 >> >> URL: http://svn.apache.org/viewvc?rev=1890693&view=rev >> Log: >> *) mod_ssl: tighten the handling of ALPN for outg

alpn in proxy connections

I tightened the ALPN handling for mod_ssl proxy connections. Since feedback on PRs works very well, I invite you to comment on this one: Cheers, Stefan

Re: APLN negotiation and TLS cross-protocols attack

> Am 10.06.2021 um 13:33 schrieb Eric Covener : > > On Thu, Jun 10, 2021 at 7:28 AM Stefan Eissing > wrote: >> >> In short: there is the possibility of a middle-man tricking a client into >> accepting the response from another TLS server, if it uses the same

APLN negotiation and TLS cross-protocols attack

In short: there is the possibility of a middle-man tricking a client into accepting the response from another TLS server, if it uses the same certificate. This seems to be in the open, so we can talk about it here. People think about how to prevent this and enforce stricter ALPN negotiation. Bu

Re: svn commit: r1890598 - in /httpd/site/trunk/content/security/json: CVE-2019-17567.json CVE-2020-13938.json CVE-2020-13950.json CVE-2020-35452.json CVE-2021-26690.json CVE-2021-26691.json CVE-2021-

> Am 09.06.2021 um 22:10 schrieb Christophe JAILLET > : > > Le 08/06/2021 à 13:42, m...@apache.org a écrit : >> Author: mjc >> Date: Tue Jun 8 11:42:36 2021 >> New Revision: 1890598 >> URL: http://svn.apache.org/viewvc?rev=1890598&view=rev >> Log: >> Fix the release date and version >> Modifi

Re: mod_proxy / mod_ssl interworking

> Am 02.06.2021 um 13:29 schrieb jean-frederic clere : > > On 01/06/2021 19:37, Stefan Eissing wrote: >>> Am 01.06.2021 um 18:21 schrieb jean-frederic clere : >>> >>> On 01/06/2021 16:40, Stefan Eissing wrote: >>>>> Am 01.06.2021 um 16:39

Re: [RESULT - PASS] Release httpd-2.4.48

> Am 02.06.2021 um 09:14 schrieb Ruediger Pluem : > > > > On 6/2/21 1:02 AM, Yann Ylavic wrote: >> On Tue, Jun 1, 2021 at 11:07 PM Christophe JAILLET >> wrote: >>> >>> 2.4.48 is live now. >>> >>> However, the mails sent on annouce@a.o and annouce@httpd.a.o seem to not >>> have reached thei

Re: mod_proxy / mod_ssl interworking

> Am 01.06.2021 um 18:21 schrieb jean-frederic clere : > > On 01/06/2021 16:40, Stefan Eissing wrote: >>> Am 01.06.2021 um 16:39 schrieb Stefan Eissing >>> : >>> >>> PR on trunk, for review and commenting: >>> https://github.com/apache

Re: mod_proxy / mod_ssl interworking

> Am 01.06.2021 um 16:39 schrieb Stefan Eissing : > > PR on trunk, for review and commenting: > https://github.com/apache/httpd/pull/190 > > This change makes it possible to have more than one SSL module handling proxy > connections. The intention is to do this in a ba

mod_proxy / mod_ssl interworking

PR on trunk, for review and commenting: https://github.com/apache/httpd/pull/190 This change makes it possible to have more than one SSL module handling proxy connections. The intention is to do this in a backward compatible way, like the previous ap_ssl_* changes. The addition of a `conn_rec-

Re: Question about APR trunk and httpd ldap modules

> Am 28.05.2021 um 03:42 schrieb William A Rowe Jr : > > On Thu, May 27, 2021, 07:52 Eric Covener wrote: > On Thu, May 27, 2021 at 8:45 AM Rainer Jung wrote: > > > is my understanding correct, that even httpd trunk (and then also 2.4.x) > > needs LDAP support in APR/APU to build mod_ldap and

Re: svn commit: r1890245 - in /httpd/httpd/branches/2.4.x: ./ docs/manual/mod/ include/ modules/http2/ server/

Thx! Fixed. > Am 27.05.2021 um 16:07 schrieb Christophe JAILLET > : > > Hi, > > Nitpicking > > CJ > > Le 27/05/2021 à 15:08, ic...@apache.org a écrit : >> Author: icing >> Date: Thu May 27 13:08:21 2021 >> New Revision: 1890245 >> >> URL: http://svn.apache.org/viewvc?rev=1890245&view=rev >>

mod_proxy/mod_ssl interworking

I believe we can improve the current interworking between mod_proxy and mod_ssl somewhat. Without repeating the current dance of calling optional functions here, I see the following things that can be done: 1. Have an "outgoing" flag in conn_rec that makes clear a connection is going from the s

https: proxies

Do I read the code correctly that httpd is not able to use https: remote proxies? This might be a somewhat esoteric feature in httpd setups, or it might have become a desirable thing in the "encrypt everything" world. I am not sure. Anyone aware of this? Cheers, Stefan

Re: [RESULT - PASS] Release httpd-2.4.48

\o/ Thanks for doing this release, Christophe! > Am 25.05.2021 um 19:58 schrieb Christophe JAILLET > : > > Hi all, > > With 8 binding PMC +1 votes, 5 additional +1 votes from the community, and no > -1 votes, I'm pleased to report that the vote has PASSED to release 2.4.48. > > The process o

Re: SSLFIPS on/off

> Am 21.05.2021 um 17:59 schrieb Joe Orton : > > On Wed, May 12, 2021 at 02:25:42PM +0200, pgajdos wrote: >> Hello, >> >> I have a question regarding the logic around SSLFIPS on/off. After >> https://svn.apache.org/viewvc?view=revision&revision=1853197 >> I think SSLFIPS off will not work as e

Re: log config and variables

Done in r1890003. > Am 17.05.2021 um 21:25 schrieb Ruediger Pluem : > > > > On 5/17/21 4:44 PM, Yann Ylavic wrote: >> On Mon, May 17, 2021 at 3:17 PM Eric Covener wrote: >>> >>> On Mon, May 17, 2021 at 8:47 AM Stefan Eissing >>> wrote: >>

Re: [VOTE] Release httpd-2.4.48

> Am 18.05.2021 um 11:52 schrieb Giovanni Bechis : > > On 5/17/21 11:36 PM, Christophe JAILLET 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 re

log config and variables

With possibly multiple SSL modules active in our server, I am looking what to do about the logging configuration. The current situation: mod_ssl registers log handler for tags "x" and "c". Those do - "x" does a lookup of the SSL_* variable name - "c" does a shorthand translation of 6 variables n

Re: NOTICE: Intent to T&R on Sunday May 16, 2021

Done. 😬😅 > Am 17.05.2021 um 13:44 schrieb Stefan Eissing : > > Christophe, > > do I still have an hour to update the mod_md documentation? > > Cheers, Stefan > >> Am 17.05.2021 um 07:54 schrieb Marion & Christophe JAILLET >> : >> >> Hi a

Re: NOTICE: Intent to T&R on Sunday May 16, 2021

Christophe, do I still have an hour to update the mod_md documentation? Cheers, Stefan > Am 17.05.2021 um 07:54 schrieb Marion & Christophe JAILLET > : > > Hi all, > > the issues that have shown up just before the announcement of 2.4.48 seem to > be gone now. > > So I'll T&R a new 2.4.48 fo

backport ap_ssl_* infrastructure

With Rüdiger probably giving his vote soon, the backport proposal for the new "ap_ssl_*" functions, together with the changes in modules to use it *and* a new mod_md with EC certificate support will make it into 2.4.x, hopefully for 2.4.48. Since is a rather large change compared to others, it

CHANGES and change entries

Team, me is confused about the status of CHANGES and changes-entries. Could we clarify for everyone how things are supposed to work now? There was some back and forth in the past, the README.CHANGES says both are valid and on backport proposals people seem to prefer the entries (which I agree w

Re: [RESULT - PASS] Release httpd-2.4.47

\o/ Thanks for RMing! > Am 28.04.2021 um 15:22 schrieb Christophe JAILLET > : > > Hi all, > > With 8 binding PMC +1 votes, 3 additional +1 votes from the community, and no > -1 votes, I'm pleased to report that the vote has PASSED to release 2.4.47. > > I will begin the process of pushing to

Re: ap_ssl_* backport

Updated the PR https://github.com/apache/httpd/pull/179 with r1889009 and recent 2.4.x changes. > Am 20.04.2021 um 12:05 schrieb Stefan Eissing : > > > >> Am 20.04.2021 um 11:57 schrieb Ruediger Pluem : >> >> >> >> On 4/13/21 3:00 PM, S

Re: recent watchdog pool changes

Ah, then I added my vote for this. Thanks for the pointer. > Am 20.04.2021 um 16:09 schrieb Joe Orton : > > On Tue, Apr 20, 2021 at 03:58:17PM +0200, Stefan Eissing wrote: >> Yann, can you have a look if this fix of mine does do the right thing? For >> me, mod_md works be

recent watchdog pool changes

Yann, can you have a look if this fix of mine does do the right thing? For me, mod_md works better when it does not use destroyed pools. 🤪 If this is ok, we might want to backport this really fast. /Stefan diff --git a/modules/core/mod_watchdog.c b/modules/core/mod_watchdog.c index d833939cb0.

Re: ap_ssl_* backport

> Am 20.04.2021 um 11:57 schrieb Ruediger Pluem : > > > > On 4/13/21 3:00 PM, Stefan Eissing wrote: >> The PR 179 <https://github.com/apache/httpd/pull/179> has been updated with >> the additions of our OCSP hook support in the core server. In case you did

ap_ssl_* backport

The PR 179 has been updated with the additions of our OCSP hook support in the core server. In case you did not follow it, a short summary of the changes: 1. httpd core offers functions/hooks so that SSL related things can be queried without optiona

OCSP stapling evolution

My thoughts on how we can evolve the OCSP Stapling infrastructure in our server: https://github.com/icing/mod_tls/issues/4 With the `ap_ssl_*()` function we replaced basic SSL function provided by mod_ssl alone so far by adding support to the core server. This is not only convenient for modules

Re: svn commit: r1888008 - /httpd/httpd/branches/2.4.x/STATUS

*subconscioussness > Am 24.03.2021 um 15:34 schrieb Stefan Eissing : > > > >> Am 24.03.2021 um 15:25 schrieb Yann Ylavic : >> >> Hi Stefan, >> >>> >>> + *) core/mod_ssl/mod_md: >>> + - adding new ap_ssl_*() functions

Re: svn commit: r1888008 - /httpd/httpd/branches/2.4.x/STATUS

> Am 24.03.2021 um 15:25 schrieb Yann Ylavic : > > Hi Stefan, > >> >> + *) core/mod_ssl/mod_md: >> + - adding new ap_ssl_*() functions for a backward >> + compatible replacement of the major optional mod_ssl functions. This >> + allows other ssl modules to work without impers

mod_tls, protocol and cipher plans

I opened an issue about protocol and cipher configuration plan in mod_tls: https://github.com/icing/mod_tls/issues/1 - Stefan

Re: "ssl" variables and "SSLRequireSSL"

> Am 12.03.2021 um 13:42 schrieb Joe Orton : > > On Fri, Mar 12, 2021 at 12:22:38PM +0100, Stefan Eissing wrote: >> Things for consideration: >> 1. "SSLOptions StdEnvVars" sets a range of variables unrelated to SSL. >> I think these should be provid

"ssl" variables and "SSLRequireSSL"

Things for consideration: 1. "SSLOptions StdEnvVars" sets a range of variables unrelated to SSL. I think these should be provided by the server. 2. "SSLRequireSSL" is internally implemented on the deprecated "SSLRequire". Should we at least recommend in the documentation which "Require" configura

Re: event.c assert failed

FTR: this has been resolved by fixing my own mistake. ;-) > Am 08.03.2021 um 13:59 schrieb Stefan Eissing : > > > >> Am 08.03.2021 um 13:49 schrieb Yann Ylavic : >> >> Hi Stefan, >> >>> >>> I see an crash and log entries: >>>

Re: svn commit: r1887342 - /httpd/httpd/trunk/modules/md/md_crypt.c

> Am 08.03.2021 um 21:50 schrieb Yann Ylavic : > > On Mon, Mar 8, 2021 at 9:15 PM wrote: >> >> +#if OPENSSL_VERSION_NUMBER < 0x1010L >> +ip = ASN1_STRING_get_data(cval->d.iPAddress); > > Looks like it's ASN1_STRING_data(), without the _get ;) Aahh! It was too late in

Re: event.c assert failed

> Am 08.03.2021 um 13:49 schrieb Yann Ylavic : > > Hi Stefan, > >> >> I see an crash and log entries: >> >> [mpm_event:error] [pid 28031:tid 4595580416] (9)Bad file descriptor: >> AH00468: error closing socket >> [core:crit] [pid 28031:tid 4595580416] AH00102: [Mon Mar 08 11:32:48 2021] >>

event.c assert failed

Hi Yann, I see an crash and log entries: [mpm_event:error] [pid 28031:tid 4595580416] (9)Bad file descriptor: AH00468: error closing socket [core:crit] [pid 28031:tid 4595580416] AH00102: [Mon Mar 08 11:32:48 2021] file event.c, line 565, assertion "0" failed when a client opens a connection a

Re: svn commit: r1887085 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_protocol.h modules/md/mod_md.c modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_pri

> Am 03.03.2021 um 13:05 schrieb Stefan Eissing : > > > >> Am 03.03.2021 um 11:36 schrieb Ruediger Pluem : >> >> >> >> On 3/3/21 11:25 AM, Stefan Eissing wrote: >>> >>> >>>> Am 03.03.2021 um 11:17 schrieb Ruediger

Re: svn commit: r1887085 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_protocol.h modules/md/mod_md.c modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_pri

> Am 03.03.2021 um 11:36 schrieb Ruediger Pluem : > > > > On 3/3/21 11:25 AM, Stefan Eissing wrote: >> >> >>> Am 03.03.2021 um 11:17 schrieb Ruediger Pluem : >>> >>> >>> >>> On 3/3/21 11:01 AM, Stefan Eissin

Re: apache subversion and github

> Am 03.03.2021 um 11:56 schrieb Joe Orton : > > On Wed, Mar 03, 2021 at 11:06:20AM +0100, Stefan Eissing wrote: >> Hi, >> >> could someone from infra shed some light on what the current status of >> the subversion/github integration is? Is there some doc

Re: svn commit: r1887085 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_protocol.h modules/md/mod_md.c modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_pri

> Am 03.03.2021 um 11:25 schrieb Stefan Eissing : > > > >> Am 03.03.2021 um 11:17 schrieb Ruediger Pluem : >> >> >> >> On 3/3/21 11:01 AM, Stefan Eissing wrote: >>> >>> >>>> Am 03.03.2021 um 10:44 schrieb Stefa

Re: svn commit: r1887085 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_protocol.h modules/md/mod_md.c modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_pri

> Am 03.03.2021 um 11:17 schrieb Ruediger Pluem : > > > > On 3/3/21 11:01 AM, Stefan Eissing wrote: >> >> >>> Am 03.03.2021 um 10:44 schrieb Stefan Eissing >>> : >>> >>> >>> >>>> Am 03.03.2021 um 10:

Re: svn commit: r1887085 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_protocol.h modules/md/mod_md.c modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_pri

> Am 03.03.2021 um 11:14 schrieb Yann Ylavic : > > On Wed, Mar 3, 2021 at 11:02 AM Stefan Eissing > wrote: >> >> Good that there is Rüdiger! > > +1 > >> >> Thinking about this: how much work would it be for mod_ssl to accept PEM >>

apache subversion and github

Hi, could someone from infra shed some light on what the current status of the subversion/github integration is? Is there some documentation about the state of things? I am asking because some devs seem to use it, there are PRs out there, but attempts to push a new branch to g...@github.com:ap

Re: svn commit: r1887085 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_protocol.h modules/md/mod_md.c modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_pri

> Am 03.03.2021 um 10:44 schrieb Stefan Eissing : > > > >> Am 03.03.2021 um 10:31 schrieb Ruediger Pluem : >> >> >> >> On 3/3/21 9:54 AM, Stefan Eissing wrote: >>>> Am 03.03.2021 um 09:35 schrieb Stefan Eissing >>>> : >

Re: svn commit: r1887085 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_protocol.h modules/md/mod_md.c modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_pri

> Am 03.03.2021 um 10:31 schrieb Ruediger Pluem : > > > > On 3/3/21 9:54 AM, Stefan Eissing wrote: >>> Am 03.03.2021 um 09:35 schrieb Stefan Eissing >>> : >>> >>> >>> >>>> Am 02.03.2021 um 20:54 schrieb Ruediger

Re: svn commit: r1887085 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_protocol.h modules/md/mod_md.c modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_pri

> Am 03.03.2021 um 09:35 schrieb Stefan Eissing : > > > >> Am 02.03.2021 um 20:54 schrieb Ruediger Pluem : >> >> >> >> On 3/2/21 3:21 PM, ic...@apache.org wrote: >>> Author: icing >>> Date: Tue Mar 2 14:21:18 2021 >>>

Re: svn commit: r1887085 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_protocol.h modules/md/mod_md.c modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_pri

> Am 02.03.2021 um 20:54 schrieb Ruediger Pluem : > > > > On 3/2/21 3:21 PM, ic...@apache.org wrote: >> Author: icing >> Date: Tue Mar 2 14:21:18 2021 >> New Revision: 1887085 >> >> URL: http://svn.apache.org/viewvc?rev=1887085&view=rev >> Log: >> Adding more ap_ssl_* functions and hooks to

Re: a patch for a ap_ssl_is_https()

> Am 23.02.2021 um 12:18 schrieb Ruediger Pluem : > > > > On 2/23/21 11:26 AM, Stefan Eissing wrote: >> >> >>> Am 23.02.2021 um 11:14 schrieb Joe Orton : >>> >>> On Mon, Feb 22, 2021 at 05:28:03PM +0100, Stefan Eissing wrote: >>&

Re: a patch for a ap_ssl_is_https()

> Am 23.02.2021 um 11:14 schrieb Joe Orton : > > On Mon, Feb 22, 2021 at 05:28:03PM +0100, Stefan Eissing wrote: >> Regarding my proposal to add SSL related inquiry functions to our core >> server, here >> is a patch for the "ssl_is_https()" function. Thi

a patch for a ap_ssl_is_https()

Regarding my proposal to add SSL related inquiry functions to our core server, here is a patch for the "ssl_is_https()" function. This allows: a) anyone to inquire about a connections SSLiness without the optional function retrieval. It will itself call such a function provided by a module.

Re: ssl infrastructure

> Am 12.02.2021 um 19:28 schrieb Eric Covener : > > On Fri, Feb 12, 2021 at 10:55 AM ste...@eissing.org > wrote: >> >> As you might know, I have started writing an Apache module to bring SSL >> using the Rust based rustls library to the server. Currently, I have base >> connection filter w

Re: make update-changes failure on MacOS

MacOS BS: > make update-changes D changes-entries/proxy_hcheck_concurrent.txt D changes-entries/no_empty_bind_password.txt Index: CHANGES === --- CHANGES (Revision 1886093) +++ CHANGES (Arbeitskopie) @@ -1,6 +1

Re: svn commit: r1782958 - in /httpd/httpd/trunk: docs/log-message-tags/ modules/http2/

psst! > Am 19.01.2021 um 16:20 schrieb Eric Covener : > >> It could be Stefan has just forgotten to merge a patch which adds a few >> thousand new log messages though? > > forgot to `svn add modules/http3`

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

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

Re: APLOGNO number range for vendors?

#define RHLOGNO(n) "RH" #n ": " and have your own number space? > Am 01.12.2020 um 15:33 schrieb Joe Orton : > > Very occasionally we backport patches to RHEL's httpd package in a way > that introduces new or different logging output from 2.4/trunk. I'm > wondering if there is an

Re: libcurl dependency version fix for mod_md

> Am 15.10.2020 um 15:28 schrieb Alexander Gerasimov > : > > Dear httpd devs, > > Please apply a small patch that fixes a minimal curl version (so mod_md can > be built on CentOS 7). > > I made a pull request https://github.com/apache/httpd/pull/108/ and filed a > bugzilla bug with a patch

Re: mod_http2 behavior in case of too many or too large request headers

> Am 10.09.2020 um 11:24 schrieb Ruediger Pluem : > > > > On 9/10/20 9:31 AM, Stefan Eissing wrote: >> >> >>> Am 10.09.2020 um 09:29 schrieb Ruediger Pluem : >>> >>> >>> >>> On 9/9/20 10:21 AM, Stefan Eissin

Re: mod_http2 behavior in case of too many or too large request headers

> Am 10.09.2020 um 09:29 schrieb Ruediger Pluem : > > > > On 9/9/20 10:21 AM, Stefan Eissing wrote: >> >> >>> Am 08.09.2020 um 21:11 schrieb Ruediger Pluem : >>> >>> >>> >>> On 9/8/20 9:22 AM, Stefan Eissin

Re: mod_http2 behavior in case of too many or too large request headers

> Am 08.09.2020 um 21:11 schrieb Ruediger Pluem : > > > > On 9/8/20 9:22 AM, Stefan Eissing wrote: >> >> >>> Am 08.09.2020 um 08:27 schrieb Ruediger Pluem : >>> >>> >>> >>> On 8/21/20 9:20 AM, Ruediger

Re: mod_http2 behavior in case of too many or too large request headers

> Am 08.09.2020 um 08:27 schrieb Ruediger Pluem : > > > > On 8/21/20 9:20 AM, Ruediger Pluem wrote: >> >> >> On 8/20/20 11:38 AM, Stefan Eissing wrote: >>> >>> >>>> Am 20.08.2020 um 11:35 schrieb Ruediger Pluem : &

Re: Changing the httpd security process

> Am 20.08.2020 um 18:24 schrieb Joe Orton : > > On Mon, Aug 17, 2020 at 12:08:35PM +0100, Joe Orton wrote: >> This roughly reverts the httpd process to what we used prior to adopting >> the Tomcat-esque policy for the whole ASF. We would have to document >> this and possibly need it approv

Re: mod_http2 behavior in case of too many or too large request headers

> Am 20.08.2020 um 11:35 schrieb Ruediger Pluem : > > > > On 8/20/20 10:47 AM, Stefan Eissing wrote: >> >> >>> Am 20.08.2020 um 10:01 schrieb Ruediger Pluem : >>> >>> >>> >>> On 8/19/20 12:18 PM, Stefan Eissin

Re: mod_http2 behavior in case of too many or too large request headers

> Am 20.08.2020 um 10:01 schrieb Ruediger Pluem : > > > > On 8/19/20 12:18 PM, Stefan Eissing wrote: >> >> >>> Am 19.08.2020 um 12:08 schrieb Ruediger Pluem : >>> >>> If mod_http2 detects too many or too large request headers in >

<    1   2   3   4   5   6   7   8   9   10   >