On Fri, Jun 19, 2015 at 12:50 PM, Jim Jagielski wrote:
> [ ] +1: Good to go
+1 AIX/xlc/PPC64 100% pass
The pre-release test tarballs for Apache httpd 2.4.15 can be found
at the usual place:
http://httpd.apache.org/dev/dist/
I'm calling a VOTE on releasing these as Apache httpd 2.4.15 GA.
[ ] +1: Good to go
[ ] +0: meh
[ ] -1: Danger Will Robinson. And why.
Vote will last the normal 72 hr
On Jun 18, 2015 1:45 PM, "William A Rowe Jr" wrote:
>
> On Jun 11, 2015 8:22 AM, "Eric Covener" wrote:
> >
> > On Thu, Jun 11, 2015 at 9:08 AM William A Rowe Jr
wrote:
> >>
> >> But withholding a security fix for legacy server users? Sounds like a
way to earn distrust of the user community, not
On Thu, Jun 18, 2015 at 12:22:21PM +0200, Yann Ylavic wrote:
> On Thu, Jun 18, 2015 at 11:49 AM, Jan Pazdziora wrote:
> >
> > I'd appreciate any comments about suitability of such change, as well
> > as the implementation. Specifically, I'm not sure if people will
> > prefer the generic and curren
On Fri, Jun 19, 2015 at 10:02 AM, Yann Ylavic wrote:
> Maybe make MAX_REQUESTS_IN_PIPELINE configurable and use 1 in your case?
that's interesting, will check it out.
On Fri, Jun 19, 2015 at 3:51 PM, Eric Covener wrote:
>
> Thanks for any ideas.
Maybe make MAX_REQUESTS_IN_PIPELINE configurable and use 1 in your case?
On Fri, Jun 19, 2015 at 9:54 AM, Jeff Trawick wrote:
> Can ap_hook_{suspend_resume}_connection() allow you to remove that
> requirement?
I don't think so -- at least not easily. It's effectively fopen() and
close() for a special kind of file (that's being served)
On 06/19/2015 09:54 AM, Jeff Trawick wrote:
On 06/19/2015 09:51 AM, Eric Covener wrote:
I have a proprietary module that uses a proprietary library. The
library needs an EOR cleanup that must run on the same thread as the
handler. During async write completion it will often happen on the
wrong
On 06/19/2015 09:51 AM, Eric Covener wrote:
I have a proprietary module that uses a proprietary library. The
library needs an EOR cleanup that must run on the same thread as the
handler. During async write completion it will often happen on the
wrong thread.
Can ap_hook_{suspend_resume}_connec
I have a proprietary module that uses a proprietary library. The
library needs an EOR cleanup that must run on the same thread as the
handler. During async write completion it will often happen on the
wrong thread.
There's already a path for forcing a blocking write of a particular
bucket, so it
Which, I see, does NOT rm and regen the certs... The certs themselves
are only good for 365 days.
This seems wrong :)
Anyway, after trashing the certs, test passes OK. Sorry for the
false alarm.
> On Jun 19, 2015, at 8:59 AM, Jim Jagielski wrote:
>
> I do a full t/TEST clean
>
>> On Jun 19, 2
I do a full t/TEST clean
> On Jun 19, 2015, at 8:56 AM, Ruediger Pluem wrote:
>
> Maybe the test certs in your test suite need regeneration, because they are
> expired?
>
> Regards
>
> Rüdiger
>
> On 06/19/2015 02:12 PM, Jim Jagielski wrote:
>> Also on trunk...
>>
>>> On Jun 19, 2015, at 8:
On my box:
t/protocol/nntp-like.t .. skipped: deferred accept()
prohibits testing with 2.1
Any (new) differ accept in Darwin?
On Fri, Jun 19, 2015 at 2:12 PM, Jim Jagielski wrote:
> Also on trunk...
>
>> On Jun 19, 2015, at 8:07 AM, Jim Jagielski wrote:
>>
>> This is on Darwin... wi
Maybe the test certs in your test suite need regeneration, because they are
expired?
Regards
Rüdiger
On 06/19/2015 02:12 PM, Jim Jagielski wrote:
> Also on trunk...
>
>> On Jun 19, 2015, at 8:07 AM, Jim Jagielski wrote:
>>
>> This is on Darwin... will test on others.
>>
>> t/protocol/nntp-lik
Also on trunk...
> On Jun 19, 2015, at 8:07 AM, Jim Jagielski wrote:
>
> This is on Darwin... will test on others.
>
> t/protocol/nntp-like.t ..
> 1..10
> # Running under perl version 5.020002 for darwin
> # Current time local: Fri Jun 19 08:04:27 2015
> # Current time GMT: Fri Jun 19 12:04:2
This is on Darwin... will test on others.
t/protocol/nntp-like.t ..
1..10
# Running under perl version 5.020002 for darwin
# Current time local: Fri Jun 19 08:04:27 2015
# Current time GMT: Fri Jun 19 12:04:27 2015
# Using Test.pm version 1.26
# Using Apache/Test.pm version 1.40
testing mod_nntp
Someone to (easy) vote for the warning issue fixed in r1684057?
On Fri, Jun 19, 2015 at 1:52 PM, Jim Jagielski wrote:
> Just a reminder...
>
> I plan on doing so by 12:30pm, Eastern.
>
>> On Jun 18, 2015, at 1:08 PM, Jim Jagielski wrote:
>>
>> Subj sez it all.
>
Just a reminder...
I plan on doing so by 12:30pm, Eastern.
> On Jun 18, 2015, at 1:08 PM, Jim Jagielski wrote:
>
> Subj sez it all.
On Fri, Jun 19, 2015 at 11:56 AM, Yann Ylavic wrote:
>
> Instead of SSL_CLIENT_OID_, we could also have something like
> SSL_CLIENTn since the underlying mod_ssl
> code handles both (IIRC).
> I don't know if SAN_otherName/UPN have a short/long name though, but many
> have.
Nope, SAN as an oi
On Fri, Jun 19, 2015 at 11:32 AM, Jan Kaluža wrote:
> On 06/18/2015 12:22 PM, Yann Ylavic wrote:
>>
>> On Thu, Jun 18, 2015 at 11:49 AM, Jan Pazdziora
>> wrote:
>>>
>>>
>>> I'd appreciate any comments about suitability of such change, as well
>>> as the implementation. Specifically, I'm not sure
On 06/18/2015 12:22 PM, Yann Ylavic wrote:
On Thu, Jun 18, 2015 at 11:49 AM, Jan Pazdziora wrote:
I'd appreciate any comments about suitability of such change, as well
as the implementation. Specifically, I'm not sure if people will
prefer the generic and currently proposed
SSL_CLIEN
21 matches
Mail list logo
