Re: BalancerPersist "relaxable" checks (was: svn commit: r1733283 - /httpd/httpd/branches/2.4.x/STATUS)

On Wed, Mar 2, 2016 at 11:47 PM, Yann Ylavic wrote: > On Wed, Mar 2, 2016 at 8:08 PM, Jim Jagielski wrote: >> >> Hmmm... iirc, if there is a mismatch, the old files are >> automagically removed. > > You are right, I was still influenced by PR58024

Re: BalancerPersist "relaxable" checks (was: svn commit: r1733283 - /httpd/httpd/branches/2.4.x/STATUS)

On Wed, Mar 2, 2016 at 8:08 PM, Jim Jagielski wrote: > > Hmmm... iirc, if there is a mismatch, the old files are > automagically removed. You are right, I was still influenced by PR58024 triggering AH02599 (painful fix), but that was due to the missing unlink() semantic on

Re: httpd-trunk/modules/http2/NWGNUmod_http2 svn EOL Setting

On Wed, Mar 2, 2016 at 11:08 PM, NormW wrote: > G/M, > Could someone with a few free seconds set the > httpd-trunk/modules/http2/NWGNUmod_http2 > file to have the appropriate svn EOL setting? Done in r1733382. Regards, Yann.

httpd-trunk/modules/http2/NWGNUmod_http2 svn EOL Setting

G/M, Could someone with a few free seconds set the httpd-trunk/modules/http2/NWGNUmod_http2 file to have the appropriate svn EOL setting? TIA Norm

Re: svn commit: r1733279 - in /httpd/httpd/branches/2.4.x: ./ STATUS server/core.c server/util_mutex.c

Attached... just in case svn.merge Description: Binary data svn.record Description: Binary data > On Mar 2, 2016, at 2:10 PM, Jim Jagielski wrote: > > yeah, I use svn.merge and svn.record (for those cases where > I use a actual patch file, but want to record the SVN

Re: svn commit: r1733279 - in /httpd/httpd/branches/2.4.x: ./ STATUS server/core.c server/util_mutex.c

yeah, I use svn.merge and svn.record (for those cases where I use a actual patch file, but want to record the SVN metadata)

Re: BalancerPersist "relaxable" checks (was: svn commit: r1733283 - /httpd/httpd/branches/2.4.x/STATUS)

> On Mar 2, 2016, at 11:13 AM, Yann Ylavic wrote: > > re: mod_proxy_hcheck backport > >> ylavic: Looks like the changes on struct proxy_worker_shared would break >> startup with "BalancerPersist on" due to the strict checks on >> the sizes

Re: conn_rec needs a context

> Am 02.03.2016 um 17:20 schrieb Graham Leggett : > > On 02 Mar 2016, at 2:26 AM, Yann Ylavic wrote: > Would it make sense to add a vector of contexts that same way we have a vector of configs, one slot for each module, which will allow any

Re: conn_rec needs a context

On 02 Mar 2016, at 2:26 AM, Yann Ylavic wrote: >>> Would it make sense to add a vector of contexts that same way we have a >>> vector of configs, one slot for each module, which will allow any module to >>> add a context of it’s own to conn_rec without having to extend

Re: svn commit: r1733239 - /httpd/httpd/trunk/modules/proxy/proxy_util.c

> Am 02.03.2016 um 17:05 schrieb Yann Ylavic : > > On Wed, Mar 2, 2016 at 10:51 AM, wrote: >> Author: icing >> Date: Wed Mar 2 09:51:05 2016 >> New Revision: 1733239 >> >> URL: http://svn.apache.org/viewvc?rev=1733239=rev >> Log: >> adding default port

Re: svn commit: r1733279 - in /httpd/httpd/branches/2.4.x: ./ STATUS server/core.c server/util_mutex.c

On Wed, Mar 2, 2016 at 5:04 PM, Eric Covener wrote: > > Dunno if this is always clear to newcomers but some of use a script called > svn.merge which helps with routine merges. > >

BalancerPersist "relaxable" checks (was: svn commit: r1733283 - /httpd/httpd/branches/2.4.x/STATUS)

re: mod_proxy_hcheck backport > ylavic: Looks like the changes on struct proxy_worker_shared would break > startup with "BalancerPersist on" due to the strict checks on > the sizes of existing slotmems (slotmem_create/attach)? > + jim: Yes, that is right (re:

Re: svn commit: r1733239 - /httpd/httpd/trunk/modules/proxy/proxy_util.c

On Wed, Mar 2, 2016 at 10:51 AM, wrote: > Author: icing > Date: Wed Mar 2 09:51:05 2016 > New Revision: 1733239 > > URL: http://svn.apache.org/viewvc?rev=1733239=rev > Log: > adding default port numbers for h2/h2x proxy schemes, by jchampion > > Modified: >

Re: svn commit: r1733279 - in /httpd/httpd/branches/2.4.x: ./ STATUS server/core.c server/util_mutex.c

On Wed, Mar 2, 2016 at 10:59 AM, Yann Ylavic wrote: > Honestly I didn't really know it was a required practice (is it?), > just always seen it in merge messages and found it useful, so just > proposed... Dunno if this is always clear to newcomers but some of use a script

Re: svn commit: r1733279 - in /httpd/httpd/branches/2.4.x: ./ STATUS server/core.c server/util_mutex.c

tl;dr I like commit messages :) On Wed, Mar 2, 2016 at 3:31 PM, Stefan Eissing wrote: > I can do that. However - smartass mode on - if one uses the actual > "svn merge -c NNN,NNN", subversion will track that and > > svn mergeinfo --show-revs merged

Re: svn commit: r1733279 - in /httpd/httpd/branches/2.4.x: ./ STATUS server/core.c server/util_mutex.c

I will add the revision numbers to the log when merging - no problem. You are correct that things can only work when everyone follows common practise, or - lacking knowledge - learns to do so. -Stefan > Am 02.03.2016 um 16:15 schrieb William A Rowe Jr : > > On Wed, Mar 2,

Re: svn commit: r1733279 - in /httpd/httpd/branches/2.4.x: ./ STATUS server/core.c server/util_mutex.c

On Wed, Mar 2, 2016 at 8:31 AM, Stefan Eissing wrote: > I can do that. However - smartass mode on - if one uses the actual > "svn merge -c NNN,NNN", subversion will track that and > > svn mergeinfo --show-revs merged ^/httpd/httpd/trunk . > > in a 2.4.x checkout

Re: svn commit: r1733279 - in /httpd/httpd/branches/2.4.x: ./ STATUS server/core.c server/util_mutex.c

I can do that. However - smartass mode on - if one uses the actual "svn merge -c NNN,NNN", subversion will track that and svn mergeinfo --show-revs merged ^/httpd/httpd/trunk . in a 2.4.x checkout will show it. But I am not trying to change existing practise here that works. And with

Re: svn commit: r1733279 - in /httpd/httpd/branches/2.4.x: ./ STATUS server/core.c server/util_mutex.c

On Wed, Mar 2, 2016 at 2:10 PM, wrote: > Author: icing > Date: Wed Mar 2 13:10:05 2016 > New Revision: 1733279 > > URL: http://svn.apache.org/viewvc?rev=1733279=rev > Log: > backport We should try to reference the backported (trunk) revisions in the commit messages. Otherwise

Re: mod_proxy_http2

> Am 02.03.2016 um 13:04 schrieb Jim Jagielski : > > I think if we could get mod_proxy_http2 and mod_proxy_hcheck into > the next 2.4.x release, we would really, really be Happy. > > :) Totally agreed. I'll try to finish up some rough edges on proxy_http2 and then make a

Re: mod_proxy_http2

I think if we could get mod_proxy_http2 and mod_proxy_hcheck into the next 2.4.x release, we would really, really be Happy. :) > On Mar 2, 2016, at 6:25 AM, Stefan Eissing > wrote: > > Yeah, that's what I thought. I just wanted to test the water temperature... >

Re: mod_proxy_http2

Yeah, that's what I thought. I just wanted to test the water temperature... > Am 02.03.2016 um 12:22 schrieb Jim Jagielski : > > I would think that it is not covered under the http2 exception > and would require a backport proposal and vote... > >> On Mar 2, 2016, at 5:06 AM,

Re: conn_rec needs a context

+1 > Am 02.03.2016 um 12:21 schrieb Jim Jagielski : > > >> On Mar 1, 2016, at 7:09 PM, Graham Leggett wrote: >> >> Hi all, >> >> In order to get connections to have async behaviour, it must be possible for >> the process_connection hook to exit in the

Re: mod_proxy_http2

I would think that it is not covered under the http2 exception and would require a backport proposal and vote... > On Mar 2, 2016, at 5:06 AM, Stefan Eissing > wrote: > > to backport or not to backport that is the question. opinions?

Re: conn_rec needs a context

> On Mar 1, 2016, at 7:09 PM, Graham Leggett wrote: > > Hi all, > > In order to get connections to have async behaviour, it must be possible for > the process_connection hook to exit in the expectation of being called again > when an async mpm is present - this is easy, the

mod_proxy_http2

to backport or not to backport that is the question. opinions?

Re: mod_speling changes in trunk and backport

Am 02.03.2016 um 08:03 schrieb Christophe JAILLET: Le 23/02/2016 20:24, Rainer Jung a écrit : There were two changes to mod_speling in trunk in 2013/2014. They were motivated by PR 44221: although the docs claim that using "CheckCaseOnly On" "limits the action of the spelling correction to