Re: backports

2022-03-08 Thread Graham Leggett
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

2022-03-07 Thread Graham Leggett
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

2022-03-06 Thread Graham Leggett
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

2022-02-25 Thread Graham Leggett
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

2022-02-09 Thread Graham Leggett
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

2022-02-09 Thread Graham Leggett
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

2022-02-09 Thread Graham Leggett
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

2022-02-08 Thread Graham Leggett
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

2022-02-07 Thread Graham Leggett
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

2022-02-07 Thread Graham Leggett
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

2022-02-07 Thread Graham Leggett
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

2022-02-07 Thread Graham Leggett
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

2022-02-07 Thread Graham Leggett
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

2022-02-07 Thread Graham Leggett
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

2022-02-06 Thread Graham Leggett
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

2022-02-06 Thread Graham Leggett
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

2022-01-26 Thread Graham Leggett
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

2022-01-25 Thread Graham Leggett
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

2022-01-25 Thread Graham Leggett
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

2022-01-25 Thread Graham Leggett
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

2022-01-24 Thread Graham Leggett
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

2022-01-24 Thread Graham Leggett
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

2022-01-24 Thread Graham Leggett
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

2022-01-24 Thread Graham Leggett
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

2022-01-24 Thread Graham Leggett
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

2022-01-24 Thread Graham Leggett
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

2022-01-24 Thread Graham Leggett
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

2022-01-24 Thread Graham Leggett
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

2022-01-24 Thread Graham Leggett
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

2022-01-24 Thread Graham Leggett
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

2022-01-24 Thread Graham Leggett
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

2022-01-23 Thread Graham Leggett
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.

2022-01-23 Thread Graham Leggett
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.

2022-01-23 Thread Graham Leggett
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

2022-01-20 Thread Graham Leggett
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

2022-01-18 Thread Graham Leggett
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

2022-01-17 Thread Graham Leggett
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

2022-01-16 Thread Graham Leggett
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/

2021-12-14 Thread Graham Leggett
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?

2021-11-24 Thread Graham Leggett
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

2021-10-03 Thread Graham Leggett
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?

2021-08-31 Thread Graham Leggett
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

2021-06-24 Thread Graham Leggett
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

2021-06-22 Thread Graham Leggett
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)

2021-01-17 Thread Graham Leggett
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

2021-01-16 Thread Graham Leggett
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

2021-01-16 Thread Graham Leggett
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

2020-12-16 Thread Graham Leggett
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

2020-12-15 Thread Graham Leggett
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

2020-12-11 Thread Graham Leggett
On 10 Dec 2020, at 18:04, yla...@apache.org wrote: > Author: ylavic > Date: Thu Dec 10 16:04:34 2020 > New Revision: 1884280 > > URL: http://svn.apache.org/viewvc?rev=1884280=rev > Log: > Revert r1480058, -1'ed on dev@ and STATUS. > > Never backported (and never will supposedly), while often

Re: Xcode 12

2020-10-29 Thread Graham Leggett
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

2020-08-09 Thread Graham Leggett
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

2020-07-30 Thread Graham Leggett
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

2020-07-22 Thread Graham Leggett
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

2020-07-15 Thread Graham Leggett
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

2020-07-15 Thread Graham Leggett
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

2020-07-15 Thread Graham Leggett
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

2020-07-15 Thread Graham Leggett
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

2020-07-15 Thread Graham Leggett
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

2020-07-06 Thread Graham Leggett
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

2020-07-03 Thread Graham Leggett
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_

2020-07-03 Thread Graham Leggett
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

2020-07-03 Thread Graham Leggett
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_

2020-07-03 Thread Graham Leggett
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

2020-06-29 Thread Graham Leggett
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_

2020-06-29 Thread Graham Leggett
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_

2020-06-29 Thread Graham Leggett
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_

2020-06-29 Thread Graham Leggett
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

2020-06-29 Thread Graham Leggett
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)

2020-06-29 Thread Graham Leggett
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: > >

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

2020-06-28 Thread Graham Leggett
On 28 Jun 2020, at 15:47, Travis CI wrote: > apache / httpd > trunk > Build #896 is still failing9 mins and 44 secs Travis mavens, I’ve been looking for the test/perl-framework directory as referred to in --with-test-suite=test/perl-framework but I’m coming up with a blank. http-tests/trunk

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

2020-06-28 Thread Graham Leggett
On 28 Jun 2020, at 15:33, Greg Stein wrote: > Hey Graham ... what's the goal with exposing these things? (this rev, and > prior) ... I don't see any emails describing "why". Generally, it would be > "shrug" ... but you're changing the MMN, and I don't see any discussion on > why/goal.

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

2020-06-28 Thread Graham Leggett
On 27 Jun 2020, at 14:48, Luca Toscano wrote: > the challenges are the same one discussed in your previous email > thread > (https://lists.apache.org/thread.html/eb086eafbd9309eb1efedac3bf3dcc410a95d06206c97e7ade01c254%40%3Cdev.httpd.apache.org%3E). > I think that everybody would love to start

Re: RFC: Documenting changes in the CHANGES file

2020-06-01 Thread Graham Leggett
On 29 May 2020, at 21:30, Ruediger Pluem wrote: > Reviewing our backport process I noticed that in many cases a clean merge via > svn merge fails due to conflicts in CHANGES. While > these are easy to solve it puts IMHO unnecessary extra work on the backport > process, both for reviewing and

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

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

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

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

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

2020-03-25 Thread Graham Leggett
On 24 Mar 2020, at 11:47, Joe Orton wrote: > On Tue, Mar 24, 2020 at 12:35:45AM +0200, Graham Leggett wrote: >> The most likely reason is because: >> >> a) http://httpd.apache.org/docs/trunk/mod/core.html#asyncfilter defaults to >> request, meaning request filters ar

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

2020-03-23 Thread Graham Leggett
On 23 Mar 2020, at 14:53, Ruediger Pluem wrote: > To sum it up: > > ap_request_core_filter might setaside an EOR and data before this and return, That’s normal. The core supports pipelining, meaning multiple requests, and therefore multiple EOR buckets can be lined up inside the core network

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

2020-03-23 Thread Graham Leggett
On 23 Mar 2020, at 09:40, Ruediger Pluem wrote: > In short: The async filter code currently corrupts responses in certain > situations. For the whole story please look here: > >

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

2020-03-22 Thread Graham Leggett
On 06 Mar 2020, at 10:30, Ruediger Pluem wrote: > Anyone found time to check > > https://github.com/apache/httpd/pull/88 > > regarding the async filter bug? Do these PRs come through on a mailing list anywhere? If there is no notification, they’ll never get seen. I immediately trip over

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

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

[Patch] mod_autht_core: Add AuthtProviderAlias for token providers

2020-03-21 Thread Graham Leggett
Hi all, Following on from mod_auth_bearer, this module provides a AuthtProviderAlias container, just like AuthnProviderAlias and AuthzProviderAlias. This time, with docs. Regards, Graham — Index: modules/aaa/mod_autht_core.c ===

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

2020-03-19 Thread Graham Leggett
On 19 Mar 2020, at 02:40, Eric Covener mailto: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 the > session / not continue to call the original auth provider. Yes - the two modules that

[Patch] mod_auth_bearer / mod_autht_jwt: An alternative to AJP

2020-03-18 Thread Graham Leggett
Hi all, With support for AJP becoming scarce, there has been a need to get information from an Apache httpd to a backend server (Tomcat, etc) in a secure way. The following patch introduces two new modules: - mod_auth_bearer: This provides bearer authentication, as described in RFC6750. A

POC: Allowing ap_process_connection() to return EAGAIN

2020-02-22 Thread Graham Leggett
Hi all, I’ve put together a proof of concept as to how ap_process_connection() might be able to return EAGAIN (or AGAIN in this case). The idea is that ap_process_connection() can return AGAIN at any time, and if so, we’ll jump ahead to where we left off and run the hook again. This way the

Re: trunk APR version requirement

2019-11-08 Thread Graham Leggett
On 08 Nov 2019, at 11:40, Joe Orton wrote: > On trunk the configure script requires APR 1.4 but mod_proxy_balancer > fails to build with APR < 1.5 since it uses apr_escape.h unconditionally > [1]. Thinking of 2.5/2.6 it might make sense to bump up the APR version > requirement to something

Re: Time for httpd 2.6.x?

2019-10-29 Thread Graham Leggett
On 29 Oct 2019, at 15:51, Jim Jagielski wrote: > My only question regards workflow w/ trunk. Right now, I think we all agree > that there are codepaths and features in trunk that are not as stable as we > would like. Which is fine... trunk is CTR. But we do need some way to vet > those

Re: Time for httpd 2.6.x?

2019-10-25 Thread Graham Leggett
On 24 Oct 2019, at 14:14, Jim Jagielski wrote: > Going from 2.4.x to 2.6.x implies an ABI break... Up to now, all backports > from trunk have maintained the 2.4.x ABI backwards compatibility. > > So I would propose that if we do the below, which I am fine w/ BTW, that the > 1st issues we

Re: Location/LocationMatch/If ordering - which one wins?

2019-07-12 Thread Graham Leggett
On 12 Jul 2019, at 09:10, Ruediger Pluem wrote: > Given Erics comments, what about: > > SSLVerifyClient optional > >=~'^\/jira\/servicedesk\/customer\/portal\/3\/(.+)\/unsubscribe(.*)'> > require all granted > 'GENEROUS’"> > # cert + group member?

Re: Location/LocationMatch/If ordering - which one wins?

2019-07-12 Thread Graham Leggett
On 12 Jul 2019, at 13:05, Eric Covener wrote: >> For a start it means that this part of our manual is invalidated the moment >> you add an If statement: >> http://httpd.apache.org/docs/current/sections.html > > I agree it's not intuitive (either way), but which part of the above > invalidated?

Re: Location/LocationMatch/If ordering - which one wins?

2019-07-12 Thread Graham Leggett
On 12 Jul 2019, at 02:51, Eric Covener wrote: > Because the last thing merged into authz_cores r->per_dir_config is a > dirconf w/ `require valid-user` directives from the if/else. > > What else could it mean for to be merged last? For a start it means that this part of our manual is

Re: Location/LocationMatch/If ordering - which one wins?

2019-07-11 Thread Graham Leggett
On 12 Jul 2019, at 01:46, Graham Leggett wrote: > I am having the exact same problem with Directory and DirectoryMatch. When > there are Ifs in a Directory, the Directory overrides the DirectoryMatch, > even though the DirectoryMatch is more specific and should “win” (win meaning &g

Re: Location/LocationMatch/If ordering - which one wins?

2019-07-11 Thread Graham Leggett
On 12 Jul 2019, at 01:32, Eric Covener wrote: >> My understanding is that we walk first to last, and the last matching >> configuration wins, and in theory that means the LocationMatch should win. > The last match doesn't win, it's merged on top of whatever the current > per-dir*per-module

Re: Location/LocationMatch/If ordering - which one wins?

2019-07-11 Thread Graham Leggett
On 12 Jul 2019, at 01:14, Eric Covener wrote: > Yes, definitely. > > - the location* are processed in config order. My understanding is that we walk first to last, and the last matching configuration wins, and in theory that means the LocationMatch should win. The trouble is Location is

Location/LocationMatch/If ordering - which one wins?

2019-07-11 Thread Graham Leggett
Hi all, I am having an odd case where my reading of the docs and httpd itself aren’t matching and I’m stumped as to why. I have a config like this (unrelated directives chopped for clarity): SSLVerifyClient optional # cert + group member? you can come in require

Re: mod_mdv2: stapling

2019-06-24 Thread Graham Leggett
On 24 Jun 2019, at 17:25, Stefan Eissing wrote: > You mean optional hooks by mod_ssl so that mod_md or someone else can take > over? Yes. I while back I was looking at supporting an arbitrary collections of certificates instead of discrete certs per virtual hosts, and the md optional

Re: mod_mdv2: stapling

2019-06-24 Thread Graham Leggett
On 24 Jun 2019, at 17:12, Stefan Eissing wrote: > General interworking mod_ssl <-> mod_md: 2 new optional functions: One quick thing I wanted to bring up a while back - rather than optional functions which can only ever be provided by a single implementation, can these be hooks instead? A

Re: svn commit: r1861947 - in /httpd/httpd/trunk: modules/filters/mod_crypto.c modules/session/mod_session_crypto.c modules/ssl/mod_ssl.c modules/ssl/ssl_engine_init.c modules/ssl/ssl_private.h server

2019-06-24 Thread Graham Leggett
On 24 Jun 2019, at 08:46, Ruediger Pluem wrote: >> URL: http://svn.apache.org/viewvc?rev=1861947=rev >> Log: >> After reinstatement of DSO support in APR/APR-util, revert r1837437, >> r1837435, r1834553, r1833598, r1833452, r1833383, r1833368. >> -#else /* USE_APR_CRYPTO_LIB_INIT */ >> -{

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

2019-05-27 Thread Graham Leggett
On 10 Feb 2019, at 12:19, jaillet...@apache.org wrote: > --- httpd/httpd/branches/2.4.x/STATUS (original) > +++ httpd/httpd/branches/2.4.x/STATUS Sun Feb 10 10:19:20 2019 > @@ -196,6 +196,7 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: > trunk patch: http://svn.apache.org/r1847430 > 2.4.x

Re: SCTP support for Apache2

2019-05-01 Thread Graham Leggett
On 01 May 2019, at 13:46, Elmar Stellnberger wrote: > There has already been an SCTP patch for Firefox as well as support for > Chrome. I believe HTTP over SCTP would be enabled quickly for all major > browsers if sufficient support from the server side was given. > My question is: Why do

  1   2   3   4   5   6   7   8   9   10   >