Re: mod_proxy_html

2011-10-13 Thread jean-frederic clere
On 10/13/2011 10:54 AM, Rainer Jung wrote: On 12.10.2011 23:56, Nick Kew wrote: On 10 Oct 2011, at 23:02, Nick Kew wrote: Any interest? Looks like a lazy consensus in favour! If you ant it a bit less lazy: +1 from me also. Regarding IP, it's mine to sign over, so that's straightforward.

Re: Really big regex results from ap_pregsub

2011-10-13 Thread Rüdiger Plüm
Am 13.10.2011 22:30, schrieb William A. Rowe Jr.: On 10/13/2011 2:32 PM, Jim Jagielski wrote: We have 2 conditions: 1. nmatch> AP_MAX_REG_MATCH 2. really big string For #1 we can either choose to return NULL or "". Since most calls to ap_pregsub() aren't checked, "" might be safer. An

Re: Really big regex results from ap_pregsub

2011-10-13 Thread William A. Rowe Jr.
On 10/13/2011 2:32 PM, Jim Jagielski wrote: > We have 2 conditions: > > 1. nmatch > AP_MAX_REG_MATCH > 2. really big string > > For #1 we can either choose to return NULL or "". Since > most calls to ap_pregsub() aren't checked, "" might be safer. > And, at least, it indicates an error (or ca

Re: Really big regex results from ap_pregsub

2011-10-13 Thread Jim Jagielski
We have 2 conditions: 1. nmatch > AP_MAX_REG_MATCH 2. really big string For #1 we can either choose to return NULL or "". Since most calls to ap_pregsub() aren't checked, "" might be safer. And, at least, it indicates an error (or can indicate one). For #2 we can choose to also limit the ret

Re: Really big regex results from ap_pregsub

2011-10-13 Thread Jim Jagielski
On Oct 13, 2011, at 2:34 PM, William A. Rowe Jr. wrote: > On 10/13/2011 9:36 AM, Jim Jagielski wrote: >> >> I propose that if nmatch>AP_MAX_REG_MATCH, we return the orig >> string. From what I can tell, we've never returned NULL, unless >> the source itself was NULL, having our failure return th

Re: Really big regex results from ap_pregsub

2011-10-13 Thread William A. Rowe Jr.
On 10/13/2011 9:36 AM, Jim Jagielski wrote: > > I propose that if nmatch>AP_MAX_REG_MATCH, we return the orig > string. From what I can tell, we've never returned NULL, unless > the source itself was NULL, having our failure return the orig > string seems safest. I can't see how this is possible.

Re: mod_proxy_html

2011-10-13 Thread Daniel Ruggeri
On 10/13/2011 3:54 AM, Rainer Jung wrote: > I'm neutral on whether to bundle or not. We would need to handle the > dependecies like for some other module when bundling, i.e. disabling the > build if the deps are not found. So long as this happens, I am +1 for bundling it. Seems it would save on so

Re: mod_proxy_html

2011-10-13 Thread Andrew Oliver
nonbinding +1 for it being bundled. That makes life a tad easier in various environments where I have to configure mod_proxy... On Thu, Oct 13, 2011 at 1:54 AM, Rainer Jung wrote: > On 12.10.2011 23:56, Nick Kew wrote: >> >> On 10 Oct 2011, at 23:02, Nick Kew wrote: >> >>> Any interest? >> >> Lo

Re: Really big regex results from ap_pregsub

2011-10-13 Thread Jim Jagielski
On Oct 12, 2011, at 3:48 PM, William A. Rowe Jr. wrote: > It doesn't seem reasonable to wait any longer to take this to dev. > I don't really need to go into the root complaint since this aspect > stands on its own. > > On 10/7/2011 3:51 PM, William A. Rowe Jr. wrote: >> On 10/7/2011 7:26 AM, Er

Re: [PATCH] New rotatelogs option to create empty logs

2011-10-13 Thread Joe Orton
On Tue, Oct 11, 2011 at 10:52:13AM +0200, Jan Kaluža wrote: > Hi, > > attached patch against trunk adds new rotatelogs option "-c" to > create logs after tRotation time even if there are no messages to > log during tRotation time. This is achieved by calling apr_poll() on > stdin with proper timeo

Re: mod_proxy_html

2011-10-13 Thread Rainer Jung
On 12.10.2011 23:56, Nick Kew wrote: > > On 10 Oct 2011, at 23:02, Nick Kew wrote: > >> Any interest? > > Looks like a lazy consensus in favour! If you ant it a bit less lazy: +1 from me also. > Regarding IP, it's mine to sign over, so that's straightforward. > So I guess it's just a matter of