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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

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?

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?

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?

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?

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?

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?

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?

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?

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?

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

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

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

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

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

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

AH02268: Proxy client certificate callback: downstream server wanted client certificate but none are configured

Hi all, I am trying to connect an httpd reverse proxy to a backend tomcat, and have this particular hop protected by a client certificate. The error I get is: [Sat Jan 05 14:02:54.252552 2019] [ssl:warn] [pid 16448:tid 139929388369664] AH02268: Proxy client certificate callback:

Re: 2.4.38

On 09 Nov 2018, at 17:51, Stefan Eissing wrote: > So, the chance is high that releases we do will work for most of you. > AND the chance is high that releases might break something for some of you > (hopefully a few). The chance is very low that releases might break something, and this is done

Re: 2.4.38

On 09 Nov 2018, at 10:05, Barry Pollard wrote: > I do wish Apache would run its own “official” repo to make upgrading to > latest easier. Don’t have the expertise to help with this and understand it > was done in the past and given up due to lack of people who did but still > think it’s a

Re: [NOTICE] Intent to T 2.4.37 - about 12:00 GMT tomorrow

On 17 Oct 2018, at 13:41, Daniel Ruggeri wrote: > Hi, all; > With the fix for detected OpenSSL 1.1.1 issues now backported to 2.4.x, I > would like to tag the next version of our venerable server soon. > > I have already successfully completed the test suite against my "latest > sources"

Re: Wherefor 2.4.36?

On 07 Oct 2018, at 03:16, Daniel Ruggeri wrote: > Actually, I'm glad you asked. I committed after 2.4.35 to T 2.4.36 soon > after. I'm happy to do that ASAP if there are no objections. > > What say you, fellow devs? How about next week? +1 and thank you. Would be good to see TLS 1.3 out the

Re: Review

On 25 Sep 2018, at 12:17, Andrei Ivanov wrote: > I'm trying again to bring this to your attention, hoping that you might have > a bit of time to take a look at the following changes made by Yann and > possibly get them into 2.4.x. > > http://svn.apache.org/r1810605 >

Re: [VOTE] Release httpd-2.4.35

On 18 Sep 2018, at 02:56, Daniel Ruggeri wrote: >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 release this > candidate tarball as 2.4.35: > [ ] +1: It's not just good,

Re: svn commit: r1841078 - in /apr/apr/trunk: CHANGES apr.dsp atomic/unix/builtins64.c atomic/unix/mutex64.c atomic/win32/apr_atomic64.c include/apr_atomic.h include/arch/unix/apr_arch_atomic.h test/t

On 17 Sep 2018, at 20:54, Yann Ylavic wrote: > How about 128bit? :p > > There are __int128 (gcc) and _m128 (MSVC) and most 64bit intel/amd > CPUs support cmpxchg16b. > Intrinsics work on gcc, and (eg.) _InterlockedCompareExchange128 on Windows. > > This can be very useful to avoid the ABA

Re: 2.4.x and 2.6.x ... next steps

On 12 Sep 2018, at 15:39, William A Rowe Jr wrote: > Now, why would we *need* a 2.5.x branch? The primary need is to remove stuff that we deem not-ready-for-2.6-yet. Modules without any docs for example would need to be either documented or removed-from-2.5-that-will-become-2.6, keeping trunk

Re: 2.4.x and 2.6.x ... next steps

On 12 Sep 2018, at 03:15, William A Rowe Jr wrote: > On Tue, Sep 11, 2018, 17:42 Graham Leggett <mailto:minf...@sharp.fm>> wrote: > On 11 Sep 2018, at 20:35, Jim Jagielski wrote: > > > This is what I propose: > > > > o Later on this week I svn cp

Re: 2.4.x and 2.6.x ... next steps

On 11 Sep 2018, at 20:35, Jim Jagielski wrote: > This is what I propose: > > o Later on this week I svn cp trunk over to branches/2.5.x > o That branch becomes the initial source for 2.6.x > o trunk remains CTR, whereas branches/2.5.x becomes RTC >ala 2.4.x (ie: using STATUS and

Re: Time for 2.4.34?

On 05 Jul 2018, at 5:43 PM, Jim Jagielski wrote: > Seems to me that we are just about due for a 2.4.34 release... > Anyone opposed? I volunteer to RM. +1, and thank you. Regards, Graham —

Re: 2.4.34 release

On 29 May 2018, at 6:13 PM, Daniel Ruggeri wrote: > I'm game for doing a T today and running the vote through Sunday (since I'm > out of town starting tomorrow) if we're ready. > > Fellow devs? +1 and thanks for this. Regards, Graham — smime.p7s Description: S/MIME cryptographic signature

Re: Experimental C unit test suite available for hacking

On 25 May 2017, at 11:44 PM, Jacob Champion wrote: > Last week I had a personal hackathon since I couldn't make it out to > ApacheCon. As a result there is now a C-language unit test suite available in > branches/httpdunit (based on trunk). I've tested it with a

Re: time for 2.4.34?

On 01 May 2018, at 11:15 PM, Jim Jagielski wrote: > Considering that we have some regressions in .33 which > will soon be fixed (these are the 2 noted ShowStoppers) > as well as a limited number of "other" changes to the > codebase, maybe now is a Good Time to consider a

Re: [VOTE] Allow for defect fix releases at httpd

On 26 Apr 2018, at 8:51 PM, William A Rowe Jr wrote: > With discussion exchanged (across several years), and various > arguments presented, we should be able to adopt or reject the > first of several possible questions as a PMC. This is the meta- > question, any versioning

Re: A proposal...

On 23 Apr 2018, at 4:00 PM, Jim Jagielski wrote: > It seems that, IMO, if there was not so much concern about "regressions" in > releases, this whole revisit-versioning debate would not have come up. This > implies, to me at least, that the root cause (as I've said before)

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

On 19 Apr 2018, at 5:11 PM, Jim Jagielski wrote: > With all this in mind, should we try to set things up so that the > next release cycle uses the concept of RCs? > > If so, and if people like, I can come up with a baseline > proposal on the process for us to debate and come

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

On 19 Apr 2018, at 10:35 PM, David Zuelke wrote: > Of course, but that's exactly my point. It was introduced not in > 2.4.0, but in 2.4.17. Five "H2…" config directives are available in > 2.4.18+ only, one in 2.4.19+, and three in 2.4.24+. H2 support was marked as

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

On 19 Apr 2018, at 5:55 PM, David Zuelke wrote: > I hate to break this to you, and I do not want to discredit the > amazing work all the contributors here are doing, but httpd 2.4 is of > miserable, miserable quality when it comes to breaks and regressions. > > I

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

On 19 Apr 2018, at 11:57 AM, Joe Orton wrote: > Feel like I should drop 2c in here... > > I'd be VERY happy to see more frequent "major" version bumps, i.e. > 2.4->2.6->2.8 or whatever which break backwards compat/ABI. We have the > chance to break compat every ~6 months

Re: "Most Popular Web Server?"

On 18 Apr 2018, at 8:32 PM, William A Rowe Jr wrote: >> You seem to be making a mountain out of a molehill [...] > > > Both statements attack not the technical question, but the questioner. > Please mind your framing. The expression “making a mountain out of a molehill”

Re: "Most Popular Web Server?"

On 18 Apr 2018, at 10:46 PM, Mark Blackman wrote: > Is most popular the right thing to aim for? I would advise continuing to > trade on Apache’s current strengths (versatility and documentation for me and > relative stability) and let the chips fall where they may. It’s an

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

On 17 Apr 2018, at 7:17 PM, Alain Toussaint wrote: >> No >> distribution (that I am aware of) ships something called Apache httpd >> v2.4.29. > > At LFS (linux from scratch), we're the exception confirming the rule of > shipping v2.4.29 with the > single patch of defining a

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

On 17 Apr 2018, at 5:40 PM, William A Rowe Jr wrote: >> I’m not following the “all in vain”. >> >> This patch in v2.4.33 was dine specifically to fix an issue in Xenial, and >> Ubuntu is on the case: >> >> https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1750356 >

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

On 17 Apr 2018, at 6:08 PM, William A Rowe Jr wrote: > No enhancement since 2011-12-19 has been presented for the collective > community's scrutiny. Again, I’m not following. The architecture of v2.4 has been very stable, the need for breaking changes has been largely non

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

On 15 Apr 2018, at 3:25 AM, Yehuda Katz wrote: > That also assumes the OS distributions pick up the point releases. RedHat > certainly doesn't pick up the new features, only bug fixes. By design - that is what “Redhat Enterprise Linux” is. Regards, Graham — smime.p7s

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

On 17 Apr 2018, at 4:41 PM, William A Rowe Jr wrote: > And everything contributed to 2.4.33 release? All in vain. None of > that in this OS distribution, because, code freeze. I’m not following the “all in vain”. This patch in v2.4.33 was dine specifically to fix an issue

Re: change the CHANGES

On 26 Mar 2018, at 6:13 PM, Jim Jagielski wrote: > Is it really all that bothersome and problematic that we need to change > things so much? What this does is add complexity and process > to the addition of CHANGES where, IMO, it doesn't belong. I > can't see adding all this

Re: [VOTE] Release httpd-2.4.31

On 07 Mar 2018, at 4:52 PM, Daniel Ruggeri wrote: > I tend to agree in principle. At the same time, we've discussed here that > version numbers are cheap and that we generally would like to release more > often, so I wanted to 'walk the talk'. Thank you for testing things

mod_proxy and SRV record support

Hi all, I have a need for an Apache mod_proxy to load balance across a number of endpoints defined by DNS SRV records. The question I have is how this might be implemented. Would it make sense, given a DNS name that matches _.+[.]_.+[.].+ (AKA _foo._bar.anything), to perform an SRV record

Re: 2.4.29 || mod_remoteip w/RemoteIPProxyProtocol

On 27 Feb 2018, at 5:00 PM, William A Rowe Jr wrote: > They had likely RTFM ... looking at > https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html#remoteipproxyprotocol > > Compatibility:RemoteIPProxyProtocol is only available in httpd 2.4.28 and > newer Fixed in

Re: 2.4.29 || mod_remoteip w/RemoteIPProxyProtocol

On 27 Feb 2018, at 4:44 PM, Jacob Perkins wrote: > I have a customer who’s attempting to use RemoteIPProxyProtocol with > mod_remoteIP. Per 2.4 documentation, this directive should be available ( > https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html >

httpd docs: -Xbootclasspath/p is no longer a supported option.

Hi all, I am getting the following when I build the httpd docs: Little-Net:build minfrin$ ./build.sh -Xbootclasspath/p is no longer a supported option. Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. I believe -Xbootclasspath/p has

Re: [VOTE] Release httpd-2.4.30

On 19 Feb 2018, at 5:45 PM, Jim Jagielski wrote: > Hmmm... I'm not seeing the patch where AP_SERVER_DEVBUILD_BOOLEAN > in ap_release.h is set to 0 > > How does your release process work? What we've always > done is make the req changes to the branch and then copy > from that

Re: [Patch] proof of concept - teaching hooks to yield where sensible

On 19 Feb 2018, at 11:45 AM, Yann Ylavic wrote: > We already have some event's mechanism(s) be async at the handler > layer (write completion, callbacks in trunk). > The "common connection state/milestone" proposal looks interesting for > compatibility (maybe add new

Re: [Patch] proof of concept - teaching hooks to yield where sensible

On 19 Feb 2018, at 11:14 AM, Stefan Eissing wrote: > If I understand your gist correctly, this would allow HTTP/2 processing to > return to the main (async) event loop more often. Which would be great. > > In the case of HTTP/2, it would be even more cool, to

[Patch] proof of concept - teaching hooks to yield where sensible

Hi all, As an extension to the idea of filters being async and being able to yield and break up their work into small chunks, I am keen to extend that idea to selected hooks. The patch below is a proof of concept, showing what it might look like if the pre_connection and process_connection

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

On 15 Feb 2018, at 5:03 PM, William A Rowe Jr wrote: > I've long been in favor of every httpd struct having an exposed _create() > function. It hadn't occurred to me to expose either a _sizeof() or _copy() > accessor, but mod_ftp could use this (until Stefan introduced the

Re: something amiss in 2.4.x

On 14 Feb 2018, at 6:16 PM, Stefan Eissing wrote: > In my h2 test suite, I get on the 2.4.x branch a no longer working propxy > setup. > > error_log shows > [Wed Feb 14 17:11:35.996712 2018] [proxy:warn] [pid 69638:tid > 123145425334272] [client 127.0.0.1:50616]

Re: Scope of RemoteIPProxyProtocol* (was: svn commit: r1824211 - /httpd/httpd/branches/2.4.x/STATUS)

On 14 Feb 2018, at 3:05 PM, Yann Ylavic wrote: > It makes sense, and actually I missed some logic w.r.t. > enabled/disabled being a list of sockaddrs (based on servers' > server_addr_rec, and not a global boolean as I first thought...). This > is later compared to incoming

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

On 14 Feb 2018, at 2:43 PM, Jim Jagielski wrote: > ++1! > > BTW: I'm fine with removing the hostname field in trunk and just having/using > hostname_ex Agreed. Will do that after the backport is done. Regards, Graham — smime.p7s Description: S/MIME cryptographic

Re: Time for 2.4.30? (Was: Re: 2.4.x STATUS needs you!)

On 14 Feb 2018, at 2:40 PM, Jim Jagielski wrote: > Yes... there are/were a few backports which are/were lacking > a single vote… We’re down to these ones left: +1: jim, minfrin +1: jailletc36, minfrin +1: minfrin Regards, Graham — smime.p7s Description:

Re: Scope of RemoteIPProxyProtocol* (was: svn commit: r1824211 - /httpd/httpd/branches/2.4.x/STATUS)

On 14 Feb 2018, at 1:03 PM, Yann Ylavic wrote: > The docs talk about connection based config, while ap_server_conf is > really the main server config. > The code should be improved to be based on c->baser_server config > (with merging of RemoteIPProxyProtocol*), unless I'm

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

On 09 Feb 2018, at 7:12 AM, William A Rowe Jr wrote:[Why] would you compare 8192 byte strings as identifiers?I just checked the code, and as I suspected the “name” field isn’t a name, or an identifier, it’s actually a URL prefix.When a balancer is found to match, the

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

On 07 Feb 2018, at 8:46 PM, William A Rowe Jr wrote: > In order to find the slot, we need to strcmp. 512 is arbitrary, does this > become an 8192 byte identifier? Or do we insist people distill names to > fit into a schema, much like DNS or file names, as the *identifier*?

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

On 07 Feb 2018, at 8:36 PM, William A Rowe Jr wrote: > But there is no argument for a name identifier >255 characters ... the cited > RFC > and the filesystem and so many others use this as the conventional constraint > on an identifier. > > Why double that? Because the

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

On 07 Feb 2018, at 8:34 PM, William A Rowe Jr wrote: > So long as other mod_proxy_* compiled against 2.4.29 do not crash, then no > - it is doesn't seem we established an ABI contract. The pairing of > httpd-2.4.30 > and the 2.4.30 mod_proxy_balancer are obviously in-sync.

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

On 07 Feb 2018, at 7:04 PM, William A Rowe Jr wrote: > These are fixed shm strings, IIRC? How is a balancer name >256 > characters usable in anything but automated strings, and the example > given by Dirk uses nowhere near 256 chars. We’re using automated strings. The

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

On 07 Feb 2018, at 5:33 PM, Jim Jagielski wrote: > +1 on removing that as fatal as well... I'll fix trunk and propose > for backport Something like this? Index: modules/proxy/proxy_util.c === ---

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

On 07 Feb 2018, at 5:34 PM, Dirk-Willem van Gulik wrote: > Not sure how this broke on your end - but the cases where I had it break on > me in production where all cases where things were generated and dynamically > registered with some sort of ``service-zone-status-etc-

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

On 07 Feb 2018, at 5:18 PM, Graham Leggett <minf...@sharp.fm> wrote: > Looking back through the archives, looks like that backport was already > accepted: > > http://svn.apache.org/viewvc?view=revision=1634520 Hmmm… it’s actually only solved the URL too long problem, the

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

On 07 Feb 2018, at 5:16 PM, Jim Jagielski wrote: >> In theory, the “accept a truncated value” will work around the problem and >> be backport-able, is that true? > > +1 (assuming the truncated value is unique) Looking back through the archives, looks like that backport was

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

On 07 Feb 2018, at 5:04 PM, Jim Jagielski wrote: > I believe the issue are the various defines in > mod_proxy.h (eg: PROXY_WORKER_MAX_NAME_SIZE. These > have been bumped up in trunk but have not been > backported to 2.4 due to perceived API/ABI issues. Looking at

BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

Hi all, Just hit this error while trying to configure a load balancer: Feb 07 14:37:31 wap01 apache2[1804]: BalancerMember worker hostname (xx-xx--x-x.xx--x.x-xxx.xxx.x.) too long According to RFC1035, DNS names are allowed to be 255 characters long. This

Re: Mistaken attributions?

On 14 Dec 2017, at 8:43 PM, William A Rowe Jr wrote: > So without diving into why one or another form is more correct, > the ASF's global license header guidance is absolute. > > mod_remoteip is an example of getting it 'right' by many > definitions of 'right' across the

Re: 2.4.x STATUS needs you!

On 13 Dec 2017, at 2:22 PM, William A Rowe Jr wrote: > Or, it is bad form to introduce features and then force some > config-changes on users after the 'experimental' phase, which > isn't even proposed, in this case. > > We want to be pretty strict about config changes, and

Re: We have soon 5 SVN repo's

On 05 Nov 2017, at 4:01 AM, Helmut K. C. Tessarek wrote: >> No, you expressed a definite unwillingness to follow our process, >> which starts by creating a patch for trunk. > > I think you misunderstood, at least partly. I don't really care, because > I don't have time to

Re: We have soon 5 SVN repo's

On 05 Nov 2017, at 12:43 AM, Helmut K. C. Tessarek wrote: >> If you aren’t willing to do the four things you’ve mentioned above, >> your code has pretty much disqualified itself from consideration, and >> what you want is largely irrelevant. > > This attitude is exactly

Re: We have soon 5 SVN repo's

On 04 Nov 2017, at 10:49 PM, Helmut K. C. Tessarek wrote: > Let's say I have a patch for the current version of Apache: 2.4.29. What > now? I have to get it first into 2.5.0 or trunk, which might not even be > compatible? Yes. > So I have to figure out how the code in

Re: We have soon 5 SVN repo's

On 04 Nov 2017, at 12:03 PM, Steffen wrote: > Soon we have: > > branches 2.4.x > trunk > 2.5.0-alpha > patches/2.4.x > patches/trunk > > Please a procedure: where and when do we apply patches/fixes. When: When you feel your change is appropriate, and when on

Re: apr "the latest available version"

On 26 Oct 2017, at 12:31 PM, Reindl Harald wrote: > i am not going to subscribe to every single devel list out there for single > issues and had already submitted a bug as 1.6.x was over months invisible > when you expect that the top part of the page is recent Please

mod_dav and PROPFIND/PROPPATCH

Hi all, The manual for mod_dav_fs is completely silent on the topic of webdav metadata on the filesystem: https://httpd.apache.org/docs/2.4/mod/mod_dav_fs.html Is the querying and setting of arbitrary filesystem metadata (xattr) supported in mod_dav_fs? If not, is anyone aware of an

Re: backport patches

On 12 Oct 2017, at 11:50 AM, Stefan Eissing wrote: > FYI: I just checked in a "patches" directory inside the 2.4.x branch. I hope > it's not picked up in a source distribution. > > If we keep patches for backports/hot-fixes here - instead of all over the > world

Re: [VOTE] Release Apache httpd 2.4.28 as GA

On 29 Sep 2017, at 12:25 PM, Reindl Harald wrote: > it's not about cheap - it's just questionable that after 2.4.12 the next > release is 2.4.16 because it looks not really sane Looks perfectly sensible to me. Regards, Graham — smime.p7s Description: S/MIME

Re: [VOTE] Release Apache httpd 2.4.28 as GA

On 28 Sep 2017, at 7:10 PM, Helmut K. C. Tessarek wrote: > I have a question. Why are you tagging a release and do testing? Most of > the time a problem is found and a new release is tagged and it starts > over (I think the max was a 3 or 4 patch level jump). > > Why not

Re: mod_authz_core: More control over the authz failed response

On 22 Sep 2017, at 12:12 PM, Yann Ylavic wrote: > I think: > ErrorDocument 403 https://somewhere/ > should work. It does indeed! https://httpd.apache.org/docs/2.4/mod/core.html#errordocument Regards, Graham — smime.p7s Description: S/MIME cryptographic signature

Re: mod_authz_core: More control over the authz failed response

On 22 Sep 2017, at 12:04 PM, Yann Ylavic wrote: >> So. I want to be able to send a 302 Temporary Redirect on authz failure, >> rather than a 403. > > Doesn't ErrorDocument work? I don’t follow, how would ErrorDocument change the response code from 403 to 302? Regards,

mod_authz_core: More control over the authz failed response

Hi all, I am currently struggling with Safari’s behaviour where it re-asks for a user certificate if the server accepted optional certificates but returned 403 Forbidden. I want the server to send the end user something sensible to explain what they should do, rather than just have their

Re: 2.4.27

On 06 Jul 2017, at 5:15 PM, Stefan Eissing wrote: > This is not a bug, it is the collision of the processing models. > > So, I think disabling it prevent user from shooting themselves in the foot. > If you are on prefork, you'd want the 6 parallel HTTP/1.1

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