Re: [WIP] mod_authnz_ldap / mod_ldap support for APR v2 LDAP API

On 19 Apr 2024, at 09:01, Ruediger Pluem wrote: > First of all I haven't gone through the patch. Hence I may be off below. > > I think the core issue with the LDAP API we have in APR-UTIL 1.x today and > that let to the > removal discussions on APR side in 2010 >

Re: [WIP] mod_authnz_ldap / mod_ldap support for APR v2 LDAP API

On 19 Apr 2024, at 09:07, Ruediger Pluem wrote: > Would it be possible to provide this patch as a PR against trunk on Github? I > think that would ease reviewing it. > I am quite aware that this moves some gory detail discussion of that patch > away from the dev list here and over > to the PR

Re: [WIP] mod_authnz_ldap / mod_ldap support for APR v2 LDAP API

On 18 Apr 2024, at 14:21, Joe Orton wrote: > This design decision seems surprising to me, what does this add? Adding > another abstraction layer to allow runtime selection of the LDAP library > seems like a step backwards (a lot of complexity with no benefit). > Unlike with e.g. a database

Re: [VOTE] Release httpd-2.4.59-rc1 as httpd-2.4.59

On 03 Apr 2024, at 13:26, Eric Covener wrote: > [ ] +1: It's not just good, it's good enough! +1 on RHEL9. Regards, Graham --

Re: mod_systemd: refactor to get rid of libsystemd dependency?

On 02 Apr 2024, at 11:25, Rainer Jung wrote: > in the light of the recent xz attack I was wondering, whether we should also > reduce our library dependencies by no longer using sd_notify() in mod_systemd > (thus loading libsystemd and all of its dependencies), but instead taking the >

Re: mod_ssl: Add support for loading keys from OpenSSL 3.x providers via STORE

On 27 Nov 2023, at 15:02, Ingo Franzki wrote: > The mod_ssl module has support for loading keys and certificates from OpenSSL > engines via PKCS#11 URIs at SSLCertificateFile and SSLCertificateKeyFile, > e.g. using the PKCS#11 engine part of libp11 > (https://github.com/OpenSC/libp11). > >

Re: svn commit: r1913977 - /httpd/httpd/trunk/modules/aaa/mod_authnz_ldap.c

On 24 Nov 2023, at 19:26, Ruediger Pluem wrote: >> We do - and we also need to apr_pstrdup() the dn to be consistent with the >> rest. > > Why? dn is already apr_pstrdup from r->pool: > >

Re: svn commit: r1913977 - /httpd/httpd/trunk/modules/aaa/mod_authnz_ldap.c

On 24 Nov 2023, at 14:25, Ruediger Pluem wrote: >> +req->dn = dn; > > Don't we need to save the vals as well? We do - and we also need to apr_pstrdup() the dn to be consistent with the rest. Index: modules/aaa/mod_authnz_ldap.c

Re: svn commit: r1913977 - /httpd/httpd/trunk/modules/aaa/mod_authnz_ldap.c

On 24 Nov 2023, at 10:03, Yann Ylavic wrote: > +1 this is pretty much what Rüdiger proposed earlier and it aligns > with the proposed 2.4.x backport so I understand better :) Rüdiger’s patch had conflicts in the time he posted it and now, I reapplied his changes in the above patch and

Re: svn commit: r1913977 - /httpd/httpd/trunk/modules/aaa/mod_authnz_ldap.c

On 20 Nov 2023, at 15:10, Ruediger Pluem wrote: > Revisiting this again. I guess the below patch should fix it. > I assume that only the checking on req != NULL is relevant. > r->user and req->dn do not matter. But we should set req->dn to dn > if util_ldap_cache_getuserdn found one. > > BTW:

Re: svn commit: r1914067 - in /httpd/httpd/trunk: changes-entries/ldap-optimise.txt modules/aaa/mod_authnz_ldap.c

On 23 Nov 2023, at 13:28, Yann Ylavic wrote: >> Unfortunately the message is correct and we do just that via >> get_dn_for_nonldap_authn (line 1451). The DN you mention we look for >> later in line 1480 via util_ldap_cache_getuserdn. > > My guess was that if r->user is set we always want to

Re: svn commit: r1914067 - in /httpd/httpd/trunk: changes-entries/ldap-optimise.txt modules/aaa/mod_authnz_ldap.c

On 23 Nov 2023, at 11:25, Ruediger Pluem wrote: >> -if (req->dn == NULL || !*req->dn) { >> -ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, APLOGNO(02636) >> - "auth_ldap authorize: require ldap-filter: user's DN " >> - "has not been defined;

Re: svn commit: r1913977 - /httpd/httpd/trunk/modules/aaa/mod_authnz_ldap.c

On 20 Nov 2023, at 15:32, Yann Ylavic wrote: > OK, I drop a new v3 here just in case and let those who know how LDAP > authn/authz work take whatever :) > This is just to show that there is some room for > factorization/disambiguation in this code.. > > > Regards; > Yann. > Just tested this,

Re: svn commit: r1913977 - /httpd/httpd/trunk/modules/aaa/mod_authnz_ldap.c

On 20 Nov 2023, at 15:10, Ruediger Pluem wrote: > Revisiting this again. I guess the below patch should fix it. > I assume that only the checking on req != NULL is relevant. > r->user and req->dn do not matter. But we should set req->dn to dn > if util_ldap_cache_getuserdn found one. > > BTW:

Re: svn commit: r1913977 - /httpd/httpd/trunk/modules/aaa/mod_authnz_ldap.c

On 20 Nov 2023, at 12:26, Ruediger Pluem wrote: > Or we need to ensure that authn_ldap_build_filter is NULL safe and returns in > a sensible way if user == NULL. This is the option we need I think - it’s possible that ldapsearch could be used without a user. Regards, Graham —

Re: svn commit: r1913962 - /httpd/httpd/trunk/modules/aaa/mod_authnz_ldap.c

On 20 Nov 2023, at 12:10, Yann Ylavic wrote: >> Fine, but if r->user is NULL here we'll segfault (NULL dereference) in >> "if (!*r->user)" here. > > Probably an unfortunate copy/paste in trunk only (not in your backport > patch3), fixed in r1913977. Thanks for this - it’s been making my head

Re: svn commit: r1913962 - /httpd/httpd/trunk/modules/aaa/mod_authnz_ldap.c

On 20 Nov 2023, at 09:32, Ruediger Pluem wrote: >> -if (sec->host) { >> +if (!sec->host) { >> +ap_log_rerror(APLOG_MARK, APLOG_WARNING, 0, r, APLOGNO(01738) > > This log message had the number 02636 before. I’ve fixed these. They don’t appear to affect the ldapsearch backport

Re: svn commit: r1913962 - /httpd/httpd/trunk/modules/aaa/mod_authnz_ldap.c

On 20 Nov 2023, at 10:44, Yann Ylavic wrote: >> URL: http://svn.apache.org/viewvc?rev=1913962=rev >> Log: >> Apply earlier fix to the ldapsearch case: >> >> Arrange for backend LDAP connections to be returned >> to the pool by a fixup hook rather than staying locked >> until the end of (a

Re: svn commit: r1591012 - in /httpd/httpd/trunk: CHANGES docs/log-message-tags/next-number modules/aaa/mod_authnz_ldap.c

On 18 Nov 2023, at 17:14, Yann Ylavic wrote: > Oh it seems that the callers want the "filtbuf" to be \0 terminated > (even in case of error), so this v2 probably.. Looking at this now. Seems to be some differences between trunk and v2.4, seeing how they can be aligned to make this easier.

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

On 18 Nov 2023, at 14:43, Yann Ylavic wrote: > Do we need an MMN bump for some ap_proxy_ functions added to > proxy_util.h (non public header), though AP_PROXY_DECLARE()d because > they need to be accessible from several proxy modules SSOs? I double checked, thought proxy_util.h was public when

Re: svn commit: r1909137 - in /httpd/httpd/trunk: CHANGES modules/mappers/mod_alias.c

On 17 Apr 2023, at 12:07, Yann Ylavic wrote: >> The question is if we find an approach to >> make it backportable e.g. by adding some kind of 2.4.x only configuration >> switch to get the behavior of r1909137. > > Maybe "AliasPerDirRelative on" (default: "off", context: "server > config,

Re: [VOTE] Switch read/write repository from Subversion to Git

On 04 May 2023, at 09:34, Ruediger Pluem wrote: > This is a formal vote on whether we should move our read/write repository > from Subversion to Git. > This means that our latest read/write repository will be no longer available > via svn.apache.org. It > will be available via Git at >

Re: ci vs PR approvals? (was: [apache/httpd] Fix a possible NULL pointer dereference in hook_uri2file (PR #355))

On 25 Apr 2023, at 07:45, Ruediger Pluem wrote: > 2. Switching from Subversion to Git is mostly an emotional problem for me. We > have some closer ties to Subversion by some > overlaps in the community and via mod_dav_svn we kind of partially eat our > very own dogfood here by using

Re: [Patch] mod_auth_bearer / mod_autht_jwt: An alternative to AJP

On 19 Mar 2020, at 12:26, Graham Leggett wrote:On 19 Mar 2020, at 02:40, Eric Covener <cove...@gmail.com> wrote:Neat, have you thought about mod_auth_form in relation to this?Something on my wishlist has been to not put the password in thesession / not continue to call the origina

Re: svn commit: r1909135 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h server/core.c

On 19 Apr 2023, at 19:08, Yann Ylavic wrote: > Currently all the tests (framework) are broken due to cmd->regex not > being properly stacked/scoped. > If cmd->regex is to be used to store the enclosing section's regex, it > should be saved and restored by *all* the the sections (much like >

POC: updated ldapi:// support for mod_ldap

Hi all, This is a patch for httpd that adds support for ldapi:// URLs to mod_ldap and friends. It depends on a patch for apr-util posted to the dev@apr list. Regards, Graham — Index: include/util_ldap.h === ---

Re: svn commit: r1909137 - in /httpd/httpd/trunk: CHANGES modules/mappers/mod_alias.c

On 14 Apr 2023, at 17:18, Ruediger Pluem wrote: > Would that break configs like > > > > Alias /filesystemprefix/%{HTTP:X-example-header} > > > > where the expression evaluation determines the complete filesystem path > without adding the remainder of the URL? It would, which alas might

Re: mod_dav and PATH_INFO - MKCOL silently creates the parent directory

On 13 Apr 2023, at 16:27, Graham Leggett wrote: > Changing the config to this makes it work: > > Alias /storage /var/www/dav/storage > > It looks like the detail that’s missing that we don’t identify the rest of > the URL after the alias and pass it on by calling alias_mat

Re: mod_dav and PATH_INFO - MKCOL silently creates the parent directory

On 13 Apr 2023, at 14:55, Graham Leggett via dev wrote: > Config looks like this: > > >Alias /var/www/dav/storage >Dav on >AcceptPathInfo On > Changing the config to this makes it work: Alias /storage /var/www/dav/storage It looks like the detail that’s

mod_dav and PATH_INFO - MKCOL silently creates the parent directory

Hi all, I am having super fun time trying to turn on mod_dav on an httpd v2.4.53-11.el9 (as shipped by RHEL9). The request “MKCOL /storage/foo” returns a 201, but doesn't actually do anything. The “foo” directory is silently not created. Stepping through the code, the code that creates the

Re: backports

On 08 Mar 2022, at 10:29, Joe Orton wrote: >> “No need to patch/compile locally" is not a good idea - currently the >> travis tests target Ubuntu only, and this is a practical limitation >> forced upon us by the nature of the Travis service. I want to see >> reviewers try out the patch on

Re: backports

On 07 Mar 2022, at 11:21, Stefan Eissing wrote: > I'd really like, as a reviewer of backports, you can: > - see that it passes all our tests. No need to patch/compile/test locally. “No need to patch/compile locally" is not a good idea - currently the travis tests target Ubuntu only, and this

Re: backports

On 04 Mar 2022, at 12:08, Stefan Eissing wrote: > We should improve our backport procedure and provide guidance on how to use > it after the next release. > > Post-mortem dbm backport: > - the patch pointed to the in 2.4.x/STATUS was incomplete, lacking APLOGNO() > - the incomplete patch was

Re: module threads and mpm lifecycle

On 23 Feb 2022, at 12:39, Stefan Eissing wrote: > One thing that is currently missing is a way to shutdown/reap/join module > threads when the mpm exits. > > Example: > > mod_watchdog creates several threads post_config which are only joined on > pool destruction. > > Problem: > > pool

Re: mpm event assertion failures

On 09 Feb 2022, at 17:43, Yann Ylavic wrote: > So ab is (appropriately?) reporting errors for kept-alive connections > that had to be shutdown earlier than KeepAliveTimeout, although I > suspect that it would report the same after the KeepAliveTimeout. ab has a code path that checks for this

Re: mpm event assertion failures

On 09 Feb 2022, at 15:08, Ruediger Pluem wrote: > Probably you get hit by this? > > https://github.com/apache/httpd/blob/46a9db4c6f9fadca4e362872021fa62a37908ece/server/mpm/event/event.c#L2096-L2101 > > If a client sends a request on a keepalive connection it should be prepared > that the

Re: mpm event assertion failures

On 08 Feb 2022, at 19:01, Yann Ylavic wrote: >> The most concurrent requests I can get out of MacOS appears to be roughly >> 2000 concurrent requests before “connection reset by peer” kills the test. >> >> One small detail I have uncovered is that a small percentage of requests >> fail,

Re: mpm event assertion failures

On 07 Feb 2022, at 18:13, Yann Ylavic wrote: > All green: https://app.travis-ci.com/github/apache/httpd/builds/246021482 > \o/ I’ve been load testing these changes with the fixed trunk version of ab, most recently modified at

Re: Python test suite - failures on Fedora Rawhide / MacOS

On 07 Feb 2022, at 12:42, Stefan Eissing wrote: >> curl -V > curl 7.77.0 (x86_64-apple-darwin21.0) libcurl/7.77.0 (SecureTransport) > LibreSSL/2.8.3 zlib/1.2.11 nghttp2/1.42.0 > Release-Date: 2021-05-26 > Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps > mqtt pop3

Re: mpm event assertion failures

On 07 Feb 2022, at 12:35, Stefan Eissing wrote: >> There are two parts that hook into the process_connection hook, the code >> you’ve cited above, and this code: >> >> void h2_c2_register_hooks(void) >> { >>/* When the connection processing actually starts, we might >> * take over, if

Re: mpm event assertion failures

On 07 Feb 2022, at 12:18, Stefan Eissing wrote: >>> Is the http2 code doing anything to work around mod_ssl trying to read, >>> failing, throwing away the error, and then pretending nothing happened? >> >> The http2 code doesn't try to work around mod_ssl, instead it does the same >> as

Re: Python test suite - failures on Fedora Rawhide / MacOS

On 07 Feb 2022, at 12:23, Stefan Eissing wrote: > could you attach a complete failed output of your pytest run? I use it on > MacOS all the time and > it seems most likely that some prerequisites have not been documented well > enough or checks must > add more information in output. I reduced

Python test suite - failures on Fedora Rawhide / MacOS

Hi all, I am not having any luck getting the python test suite to run on either MacOS or Rawhide. In the case of MacOS I see this: == 50 failed, 214 passed, 239 skipped, 195 errors in 282.97s (0:04:42) === A selection of errors:

Re: svn commit: r1897458 - in /httpd/httpd/trunk: changes-entries/ab-ssl-sense-fix.txt support/ab.c

On 27 Jan 2022, at 09:53, Ruediger Pluem wrote: >> Modified: httpd/httpd/trunk/support/ab.c >> URL: >> http://svn.apache.org/viewvc/httpd/httpd/trunk/support/ab.c?rev=1897458=1897457=1897458=diff >> >>

Re: mpm event assertion failures

On 25 Jan 2022, at 23:25, Graham Leggett wrote: > Is the http2 code doing anything to work around mod_ssl trying to read, > failing, throwing away the error, and then pretending nothing happened? The http2 code doesn't try to work around mod_ssl, instead it does the same as mod_ssl,

Re: SSL handshake nonblocking as PR

On 04 Feb 2022, at 14:49, Stefan Eissing wrote: > https://github.com/apache/httpd/pull/293 > > is the PR that contains the changes I just reverted > in trunk regarding the non-blocking SSL handshake. > > I did not like to revert a set of changes by anyone > here. But our trunk CI is failing

Re: mpm event assertion failures

On 26 Jan 2022, at 13:49, Stefan Eissing wrote: > Guys, we have changes in a central part of the server and our CI fails.=20= > > It is not good enough to give other people unspecific homework to fix = > it.=20 > > Analyze what you broke and if we can help, we'll happily do that. But > you

Re: mpm event assertion failures

On 25 Jan 2022, at 14:11, Stefan Eissing wrote: > Also, while running the http2 test suite, I get repeated assert failures in > event.c:1230 > > if (rv != APR_SUCCESS && !APR_STATUS_IS_EEXIST(rv)) { > -> AP_DEBUG_ASSERT(0); >TO_QUEUE_REMOVE(cs->sc->wc_q, cs); >

Re: trunk test failure, SSL handshake

On 25 Jan 2022, at 13:57, Stefan Eissing wrote: > Failure in https://app.travis-ci.com/github/apache/httpd/jobs/556778281 > indicates that the SSL handshake timeout no longer is working. > Also logs mpm:error several times. > > The test opens a socket and sends one byte, then waits for > the

Re: http and http/1.x separation

On 24 Jan 2022, at 16:53, Stefan Eissing wrote: > Yes, it's 0 length like ERROR and has a struct as that holds: > - int status, opt 0 > - const char *reason, opt NULL > - apr_table_t *headers > - apr_table_t *notes > > on responses, shallow copied from the request_rec, etc. > > The nice thing

Re: svn commit: r1897281 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/scoreboard.h modules/generators/mod_status.c modules/ssl/mod_ssl.c modules/ssl/ssl_engine_io.c server/mpm/event/event

On 24 Jan 2022, at 19:39, Yann Ylavic wrote: --- httpd/httpd/trunk/server/mpm/event/event.c (original) +++ httpd/httpd/trunk/server/mpm/event/event.c Fri Jan 21 00:09:24 2022 @@ -1142,6 +1145,7 @@ read_request: */ if (rc != OK || (cs->pub.state >= CONN_STATE_NUM)

Re: svn commit: r1897281 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/scoreboard.h modules/generators/mod_status.c modules/ssl/mod_ssl.c modules/ssl/ssl_engine_io.c server/mpm/event/event

On 24 Jan 2022, at 18:07, Yann Ylavic wrote: >> Well, this is after check_time_left().. > > Yet we should update the socket timeout for AP_MODE_INIT since it's > how handshakes are performed.. > Done in r1897422. Thank you for this. Regards, Graham —

Re: svn commit: r1897281 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/scoreboard.h modules/generators/mod_status.c modules/ssl/mod_ssl.c modules/ssl/ssl_engine_io.c server/mpm/event/event

On 24 Jan 2022, at 13:56, Yann Ylavic wrote: >> --- httpd/httpd/trunk/server/mpm/event/event.c (original) >> +++ httpd/httpd/trunk/server/mpm/event/event.c Fri Jan 21 00:09:24 2022 >> @@ -1142,6 +1145,7 @@ read_request: >> */ >> if (rc != OK || (cs->pub.state >= CONN_STATE_NUM) >>

Re: svn commit: r1897281 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/scoreboard.h modules/generators/mod_status.c modules/ssl/mod_ssl.c modules/ssl/ssl_engine_io.c server/mpm/event/event

On 24 Jan 2022, at 17:21, Yann Ylavic wrote: > Maybe the resume_suspended hook is a misnomer? We also have the > suspend_connection and resume_connection hooks which mean the opposite > (called when added to and removed from the queues respectively). The ap_mpm_resume_suspended() is a function

Re: svn commit: r1897387 - in /httpd/httpd/trunk: docs/log-message-tags/next-number modules/ssl/mod_ssl.c

On 24 Jan 2022, at 16:45, Yann Ylavic wrote: >> True - changed to AP_FILTER_ERROR in r1897418, which is the correct code for >> this. > > Would it work if ssl_hook_process_connection() handled only EAGAIN and > otherwise always returned DECLINED (expecting that the usual > processing would

Re: svn commit: r1897281 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/scoreboard.h modules/generators/mod_status.c modules/ssl/mod_ssl.c modules/ssl/ssl_engine_io.c server/mpm/event/event

On 24 Jan 2022, at 15:52, Yann Ylavic wrote: >> SUSPENDED already has the opposite meaning, in that a suspended connection >> will be excluded from run_process_connection() until such time as some other >> event has occurred (response on DNS, a proxy connection received something, >> etc) and

Re: svn commit: r1897387 - in /httpd/httpd/trunk: docs/log-message-tags/next-number modules/ssl/mod_ssl.c

On 24 Jan 2022, at 14:33, Yann Ylavic wrote: > I mean not only mod_ssl could return an error for > ap_get_brigade(AP_MODE_INIT), APR_EGENERAL is not distinctive enough > IMHO. True - changed to AP_FILTER_ERROR in r1897418, which is the correct code for this. Regards, Graham —

Re: http and http/1.x separation

On 24 Jan 2022, at 16:28, Stefan Eissing wrote: > The main idea is to introduce a META "HEADERS" bucket that is used for > final/interim responses and footers as well. This will safely pass through > all filters that do not know about it. This is similar to the ERROR bucket > type we already

Re: svn commit: r1897281 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/scoreboard.h modules/generators/mod_status.c modules/ssl/mod_ssl.c modules/ssl/ssl_engine_io.c server/mpm/event/event

On 24 Jan 2022, at 13:56, Yann Ylavic wrote: >> --- httpd/httpd/trunk/server/mpm/event/event.c (original) >> +++ httpd/httpd/trunk/server/mpm/event/event.c Fri Jan 21 00:09:24 2022 >> @@ -1142,6 +1145,7 @@ read_request: >> */ >> if (rc != OK || (cs->pub.state >= CONN_STATE_NUM) >>

Re: svn commit: r1897281 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/scoreboard.h modules/generators/mod_status.c modules/ssl/mod_ssl.c modules/ssl/ssl_engine_io.c server/mpm/event/event

On 24 Jan 2022, at 14:13, Yann Ylavic wrote: >> Maybe it is not needed for the handshake any longer, but it allows fine >> grained timeouts on reading speed for headers and request >> bodies which I am not sure event could deal with. At least it cannot now. > > It's not needed for the

Re: svn commit: r1897336 - in /httpd/httpd/trunk: modules/ssl/mod_ssl.c support/ab.c

On 24 Jan 2022, at 11:37, Ruediger Pluem wrote: > How is the above related to this commit? Yuck, it’s not. Taken out in r1897408. Regards, Graham —

Re: svn commit: r1897281 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/scoreboard.h modules/generators/mod_status.c modules/ssl/mod_ssl.c modules/ssl/ssl_engine_io.c server/mpm/event/event

On 22 Jan 2022, at 15:01, Yann Ylavic wrote: >> @@ -268,12 +268,14 @@ struct timeout_queue { >> /* >> * Several timeout queues that use different timeouts, so that we always can >> * simply append to the end. >> + * read_line_quses vhost's TimeOut FIXME - we can use a short >>

Re: [GitHub] [httpd-site] rbowen merged pull request #7: Drops link to 1.3 docs, which are gone.

On 23 Jan 2022, at 20:13, Yehuda Katz wrote: > Since 1.3 isn't supported, it would probably be better to remove the entries > from Wikipedia or point them to the Internet Archive. Happy to do that. Wikipedia is an encyclopaedia and therefore it is entirely valid to document historical

Re: [GitHub] [httpd-site] rbowen merged pull request #7: Drops link to 1.3 docs, which are gone.

On 21 Jan 2022, at 19:48, GitBox wrote: > rbowen merged pull request #7: > URL: https://github.com/apache/httpd-site/pull/7 Can we put the 1.3 docs back? Pages like this make extensive reference to them: https://en.wikipedia.org/wiki/List_of_Apache_modules Regards, Graham —

Re: svn commit: r1897156 - in /httpd/httpd/trunk: CHANGES docs/log-message-tags/next-number docs/manual/mod/core.xml modules/dav/main/mod_dav.c server/core.c

On 19 Jan 2022, at 09:40, Ruediger Pluem wrote: >> @@ -723,6 +737,57 @@ static int dav_get_overwrite(request_rec >> return -1; >> } >> >> +static int uripath_is_canonical(const char *uripath) > > Isn't this a filesystem path we are talking about in the case? > How does this function work

Re: svn commit: r1897156 - in /httpd/httpd/trunk: CHANGES docs/log-message-tags/next-number docs/manual/mod/core.xml modules/dav/main/mod_dav.c server/core.c

On 18 Jan 2022, at 12:31, Ruediger Pluem wrote: > Not sure I get the intention correct, but this looks like a change to core > for a mod_dav specific short coming. It's not specific to mod_dav, no. I created a patch ages ago for mod_dav_svn that depended on this patch and this got buried

Re: TLS neverbleed design

On 17 Jan 2022, at 19:17, Ruediger Pluem wrote: >> I see. Thanks for the clarification. Did not really now about that >> interface. Then I see no pressing point in adding an additional API, indeed. > > I haven't looked deeply in this, but based on the pointers from Joe I guess > this can be

Re: svn commit: r1897123 - /httpd/httpd/patches/2.4.x/httpd-2.4-ldap-expr.patch

On 16 Jan 2022, at 18:54, Yann Ylavic wrote: > Maybe "ldap_escape" would be a more appropriate name, should there be > a need for another ldap function (e.g. "ldap_unescape") later? This doesn’t follow the existing “short” naming pattern of the existing entries. I image that we’d add something

Broken links at https://httpd.apache.org/docs/

Hi all, The v1.3 historical docs link at https://httpd.apache.org/docs/ currently leads to a 404, is that intentional? Regards, Graham —

Re: mod_tls as experimental module?

On 18 Nov 2021, at 19:48, ste...@eissing.org wrote: > How would you feel about adding mod_tls > (https://github.com/abetterinternet/mod_tls) as an experimental module to > Apache httpd? Having more choice is excellent. > For people who have not followed that development: > - it is a TLS

Re: [VOTE] Release httpd-2.4.50-rc1 as httpd-2.4.50

On 1 Oct 2021, at 15:41, ste...@eissing.org wrote: > I would like to call a VOTE over the next few days to release > this candidate tarball httpd-2.4.50-rc1 as 2.4.50: > [ ] +1: It's not just good, it's good enough! +1 on CentOS7. Regards, Graham —

Re: release?

On 30 Aug 2021, at 12:35, ste...@eissing.org wrote: > In what state is our release handling? Given someone holding my hand, could > I do it? Or is it better to look someone over the shoulder while he does it? When I did it in the past, I walked through the commit emails of previous releases,

Re: Question about APR trunk and httpd ldap modules

On 27 May 2021, at 14:45, 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 mod_authnz_ldap? > > So since we removed LDAP support from APR trunk, that means those modules > currently can not be

Re: svn commit: r1890947 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS include/ap_mmn.h modules/proxy/mod_proxy.h modules/proxy/mod_proxy_ajp.c modules/proxy/mod_proxy_balancer.c modules/proxy/m

On 22 Jun 2021, at 09:09, Ruediger Pluem wrote: >> +timeout = apr_time_from_sec(10); /* 10 seconds */ > > Sorry for jumping on this late, but as I already mentioned on the original > trunk revision a hard coded timeout is bad. > Please also backport r1887439. For the record I am +1 on

Re: Broken: apache/httpd#1394 (2.4.x - fa22b50)

Hi all, https://travis-ci.com/github/apache/httpd/builds/213431494?utm_medium=notification_source=email failed for what looks like missing perl libraries: t/modules/proxy_websockets.t Can't locate AnyEvent/WebSocket/Client.pm in @INC (you may need to install the

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

On 07 Jan 2021, at 19:54, yla...@apache.org wrote: > + ylavic: +1 from covener dropped after adding r1885239, r1885240 and > + r1885244 in v2. Would it be possible to take a second look at this @covener? I am imagining proposals after this one might conflict if not done in

make update-changes failure on MacOS

Hi all, A quick heads up on the update-changes mechanism, on MacOS the mechanism fails as follows, and the CHANGES file is lost (but retrievable from svn): Little-Net:httpd-2.4.x-3 minfrin$ make update-changes awk: invalid -v option awk: invalid -v option It looks like the -v option is not

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

On 12 Dec 2020, at 01:59, Roy T. Fielding wrote: > 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

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

On 11 Dec 2020, at 14:13, Yann Ylavic wrote: > Where is this test suite? To fill you in, the Co-Advisor test suite is a commercial HTTP suite available here: http://coad.measurement-factory.com A number of years ago they donated to our project one year access to their suite for free, a

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

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=rev > Log: > Revert r1480058, -1'ed on dev@ and STATUS. > > Never backported (and never will supposedly), while often

Re: Xcode 12

On 29 Oct 2020, at 14:05, Jim Jagielski wrote: > Anyone hacking away on httpd and/or APR w/ Xcode 12? On my system at least > it is throwing errors about -Werror,-Wimplicit-function-declaration, and not > enabling IPv6: > >checking if APR supports IPv6... no -- no working getaddrinfo >

ap_expr_exec() and Vary: Vary remains unset if we parse a string

Hi all, I just been digging into why the Vary header is not set when generating a string expression with ap_expr_exec(). We currently set the Vary header when evaluating a condition: https://github.com/apache/httpd/blob/53b5c234e90db489197935b84c0066c9ec083038/server/util_expr_eval.c#L1182

Re: [VOTE] Release httpd-2.4.45

On 30 Jul 2020, at 11:16, Steffen Land wrote: > +1 on Windows. > > I am in doubt for a -0 : > > Still quite some (more) warnings, now 432, attached Win64 warnings with the > ones from APR-UTIL. > > I think a goal is (must be) that we get warning free on all platforms, now it > looks bad on

Re: NOTICE: Intent to T late this week

On 23 Jul 2020, at 01:32, Daniel Ruggeri wrote: > It's been a while since we've rolled a release and gotten fixes/etc in our > community's hands. Apologies for not suggesting this sooner. How about a T > Friday? That will let vote run through the weekend. +1. Regards, Graham —

Re: svn commit: r1879591 - in /httpd/httpd/trunk: configure.in server/log.c

On 15 Jul 2020, at 16:27, Joe Orton wrote: >> Looks like ac_cv_func_gettid is no but ap_cv_gettid is yes. > > This is not consistent with what you posted before. Looking again, the > old configure output you posted has: > > checking for gettid()... yes > > note the (), which is only

Re: svn commit: r1879888 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h modules/dav/main/mod_dav.h modules/dav/main/util.c

On 15 Jul 2020, at 15:33, Greg Stein wrote: > Seems these helper functions would be a better fit within apr_xml, rather > than httpd. In the long term, yes. In the “it must be practical to use this with v2.4” term, I’d rather continue with the established pattern, and then move the lot of

Re: svn commit: r1879889 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h modules/dav/main/mod_dav.h modules/dav/main/props.c

On 15 Jul 2020, at 16:18, Greg Stein wrote: > You're already changing the API ... why not simply introduce insert_prop_v2() > with the appropriate parameters? This concept of "pass parameters via the > pool" is very disturbing. Changes to these provider APIs can’t be backported, thus the

Re: svn commit: r1879591 - in /httpd/httpd/trunk: configure.in server/log.c

On 15 Jul 2020, at 15:35, Joe Orton wrote: >> checking for gettid()... yes > > Interesting, can you provide the config.log and "rpm -q glibc"? With a > RHEL8 vm here it does not detect gettid (as I'd expect for glibc 2.28) > and builds fine. A quick and dirty search across config.log shows

Re: svn commit: r1879591 - in /httpd/httpd/trunk: configure.in server/log.c

On 07 Jul 2020, at 15:40, jor...@apache.org wrote: > Author: jorton > Date: Tue Jul 7 13:40:15 2020 > New Revision: 1879591 > > URL: http://svn.apache.org/viewvc?rev=1879591=rev > Log: > Check for and use gettid() directly if available; glibc 2.30 and later > provides a wrapper for the system

Re: svn commit: r1879488 - /httpd/httpd/trunk/server/util_etag.c

On 06 Jul 2020, at 09:28, Ruediger Pluem wrote: >> +apr_sha1_init(); >> +nbytes = sizeof(buf); >> +while ((status = apr_file_read(fd, buf, )) == APR_SUCCESS) { > > Why do we still use apr_file_read in case we use MMAP? IMHO we should use > apr_mmap_offset. > But we would need to

Re: iOS 14 / macOS 11 and HTTP/3 support

On 29 Jun 2020, at 10:16, Stefan Eissing wrote: >> The main point is that it must be done carefully and properly, but this is >> not a reason to not do it at all. > > Apache httpd is a very strong HTTP/1.x server. And your efforts to make > response streaming more event driven have been

Re: svn commit: r1879285 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/core.xml include/ap_mmn.h include/http_core.h include/http_protocol.h include/httpd.h modules/dav/fs/repos.c modules/test/mod_

On 03 Jul 2020, at 11:19, Ruediger Pluem wrote: > Thanks for the pointer. Is Content-MD5 really used? And given that it has > been removed in the RFC my approach would be as follows: > > 1. Continue with your new additions as is. Do not try to merge any of this > code with Content-MD5 related

Re: svn commit: r1879465 - /httpd/httpd/trunk/server/util_etag.c

On 03 Jul 2020, at 11:02, Ruediger Pluem wrote: >> apr_sha1_init(); >> nbytes = sizeof(buf); >> -while (apr_file_read(fd, buf, ) == APR_SUCCESS) { >> +while ((status = apr_file_read(fd, buf, )) == APR_SUCCESS) { > > Don't we need to set the fp in fd via

Re: svn commit: r1879285 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/core.xml include/ap_mmn.h include/http_core.h include/http_protocol.h include/httpd.h modules/dav/fs/repos.c modules/test/mod_

On 29 Jun 2020, at 16:37, Ruediger Pluem wrote: > Makes sense. > Do you see a possibility to merge this code and the one of ap_md5digest to a > more generic procedure that > allows to choose the digest algorithm while using 'MMAPED' reads? > BTW: Is sha1 mandatory for strong etags? If not

Re: svn commit: r1862270 - in /httpd/httpd/trunk/modules/dav: fs/dbm.c fs/repos.c main/mod_dav.c main/props.c main/std_liveprop.c main/util.c

On 28 Jun 2019, at 10:50, rpl...@apache.org wrote: > * Replace apr_psprintf with apr_pstrcat where the format strings only > contain %s to improve efficiency. Leave out error messages as they > are not on a crtical code path and error message become less readable > when taking out the format

Re: svn commit: r1879285 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/core.xml include/ap_mmn.h include/http_core.h include/http_protocol.h include/httpd.h modules/dav/fs/repos.c modules/test/mod_

On 29 Jun 2020, at 14:49, Yann Ylavic wrote: >> Yes we can and should (but in separate commits). >> >> I have my eye on the r->proxyreq flag, we can pack this into the binary >> notes too, values don’t need to be one bit wide. > > Actually I was thinking the other way around, have the new

Re: svn commit: r1879285 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/core.xml include/ap_mmn.h include/http_core.h include/http_protocol.h include/httpd.h modules/dav/fs/repos.c modules/test/mod_

On 29 Jun 2020, at 11:41, Ruediger Pluem wrote: >> +etag = apr_palloc(r->pool, weak_len + sizeof("\"\"") + >> +4*(APR_SHA1_DIGESTSIZE/3) + vlv_len + 4); > > Using apr_base64_encode_len in the formula above would make it easier to > understand and read IMHO. It would

Re: svn commit: r1879285 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/core.xml include/ap_mmn.h include/http_core.h include/http_protocol.h include/httpd.h modules/dav/fs/repos.c modules/test/mod_

On 29 Jun 2020, at 13:08, Yann Ylavic wrote: >> /** >> * @defgroup module_magic Module Magic mime types >> @@ -1097,6 +1138,11 @@ struct request_rec { >> * TODO: compact elsewhere >> */ >> unsigned int flushed:1; >> +/** Request flags associated with this request. Use >> +

Re: svn commit: r1879307 - /httpd/httpd/trunk/modules/dav/main/mod_dav.c

On 29 Jun 2020, at 12:10, Ruediger Pluem wrote: >> +result = dav_run_deliver_report(r, resource, doc, >> +r->output_filters, ); >> +switch (result) { >> +case OK: >> return DONE; > > What happens if err != NULL. Should we handle that here like in the default >

Re: Still Failing: apache/httpd#896 (trunk - 9af2218)

On 29 Jun 2020, at 09:19, Joe Orton wrote: > The litmus tests are failing, not the perl-framework tests: > > https://travis-ci.org/github/apache/httpd/jobs/702768269#L2491 Ah - that’s where I was going wrong. > You can also see that there are segfaults logged from line 2519 onwards: > >

  1   2   3   4   5   6   7   8   9   10   >