Re: svn commit: r1808230 - /httpd/httpd/trunk/server/protocol.c

On Fri, Sep 22, 2017 at 1:02 PM, Joe Orton wrote: > On Fri, Sep 22, 2017 at 11:39:54AM -0500, William A Rowe Jr wrote: >> This defect still appears to exist in 2.4.28-dev, no? >> >> The rewrite appears to have enjoyed both committer and external testing and >> the patch looks

Re: svn commit: r1808230 - /httpd/httpd/trunk/server/protocol.c

On Fri, Sep 22, 2017 at 11:39:54AM -0500, William A Rowe Jr wrote: > This defect still appears to exist in 2.4.28-dev, no? > > The rewrite appears to have enjoyed both committer and external testing and > the patch looks suitable for backport. It has enjoyed careful consideration by > at least

Re: Time for 2.4.28 ?

On Fri, Sep 22, 2017 at 1:25 PM, Jim Jagielski wrote: > We can wait. No reason to rush if we can hold off for a bit > and ensure that 2.4.28 is as ready to go as possible. Since the C-L issue is not a (recent) regression, I would just as well bank the aging CVE fix now with a

Re: Time for 2.4.28 ?

We can wait. No reason to rush if we can hold off for a bit and ensure that 2.4.28 is as ready to go as possible. > On Sep 22, 2017, at 1:23 PM, William A Rowe Jr wrote: > > On Fri, Sep 22, 2017 at 7:06 AM, Jim Jagielski wrote: >> STATUS looks clean. >>

Re: Time for 2.4.28 ?

On Fri, Sep 22, 2017 at 7:06 AM, Jim Jagielski wrote: > STATUS looks clean. > > Hoping to do a T this afternoon, eastern, unless I hear > any objections or concerns re: timing. svn looks good here. Only one potentially missed item IMO, it could wait till 2.4.29, but if we hear

Re: svn commit: r1808230 - /httpd/httpd/trunk/server/protocol.c

This defect still appears to exist in 2.4.28-dev, no? The rewrite appears to have enjoyed both committer and external testing and the patch looks suitable for backport. It has enjoyed careful consideration by at least four committers. Reading

Re: SSLSrvConfigRec shared

I added the 'flags' getter in r1809311, much cleaner, thanks! On Fri, Sep 22, 2017 at 2:48 PM, Eric Covener wrote: > Whoops I see you already folllowed it up. > > On Fri, Sep 22, 2017 at 8:46 AM, Eric Covener wrote: >> On Fri, Sep 22, 2017 at 8:11 AM, Yann

Re: SSLSrvConfigRec shared

posticipate - realizing, while one writes a reply, that Yann has probably already implemented it. X-) > Am 22.09.2017 um 14:48 schrieb Eric Covener : > > Whoops I see you already folllowed it up. > > On Fri, Sep 22, 2017 at 8:46 AM, Eric Covener wrote:

Re: SSLSrvConfigRec shared

Whoops I see you already folllowed it up. On Fri, Sep 22, 2017 at 8:46 AM, Eric Covener wrote: > On Fri, Sep 22, 2017 at 8:11 AM, Yann Ylavic wrote: >> On Thu, Sep 21, 2017 at 2:51 PM, Eric Covener wrote: >>> On Thu, Sep 21, 2017 at

Re: SSLSrvConfigRec shared

On Fri, Sep 22, 2017 at 8:11 AM, Yann Ylavic wrote: > On Thu, Sep 21, 2017 at 2:51 PM, Eric Covener wrote: >> On Thu, Sep 21, 2017 at 8:44 AM, Yann Ylavic wrote: >>> On Thu, Sep 21, 2017 at 2:11 PM, Eric Covener

Re: svn commit: r1809302 - in /httpd/httpd/trunk: include/ap_mmn.h include/http_config.h server/config.c

On Fri, Sep 22, 2017 at 2:31 PM, Joe Orton wrote: > On Fri, Sep 22, 2017 at 11:58:53AM -, yla...@apache.org wrote: >> --- httpd/httpd/trunk/include/ap_mmn.h (original) >> +++ httpd/httpd/trunk/include/ap_mmn.h Fri Sep 22 11:58:53 2017 > ... >> @@ -562,7 +563,7 @@ >>

Re: svn commit: r1809302 - in /httpd/httpd/trunk: include/ap_mmn.h include/http_config.h server/config.c

On Fri, Sep 22, 2017 at 11:58:53AM -, yla...@apache.org wrote: > --- httpd/httpd/trunk/include/ap_mmn.h (original) > +++ httpd/httpd/trunk/include/ap_mmn.h Fri Sep 22 11:58:53 2017 ... > @@ -562,7 +563,7 @@ > #ifndef MODULE_MAGIC_NUMBER_MAJOR > #define MODULE_MAGIC_NUMBER_MAJOR 20161018 >

Re: SSLSrvConfigRec shared

On Thu, Sep 21, 2017 at 2:51 PM, Eric Covener wrote: > On Thu, Sep 21, 2017 at 8:44 AM, Yann Ylavic wrote: >> On Thu, Sep 21, 2017 at 2:11 PM, Eric Covener wrote: >>> >>> IIUC it should be safe to extend module_struct with a minor bump

Re: Time for 2.4.28 ?

STATUS looks clean. Hoping to do a T this afternoon, eastern, unless I hear any objections or concerns re: timing. Cheers!

Re: SSLSrvConfigRec shared

The patches look great! Will test on next occasion! Thanks! :) > Am 22.09.2017 um 14:02 schrieb Yann Ylavic : > > On Thu, Sep 21, 2017 at 2:54 PM, Yann Ylavic wrote: >> On Thu, Sep 21, 2017 at 2:51 PM, Eric Covener wrote: >>> On

Re: SSLSrvConfigRec shared

On Thu, Sep 21, 2017 at 2:54 PM, Yann Ylavic wrote: > On Thu, Sep 21, 2017 at 2:51 PM, Eric Covener wrote: >> On Thu, Sep 21, 2017 at 8:44 AM, Yann Ylavic wrote: >>> On Thu, Sep 21, 2017 at 2:11 PM, Eric Covener

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 Fri, Sep 22, 2017 at 12:05 PM, Graham Leggett wrote: > 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

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,

Re: mod_authz_core: More control over the authz failed response

Hi Graham, On Fri, Sep 22, 2017 at 11:57 AM, Graham Leggett wrote: > > So. I want to be able to send a 302 Temporary Redirect on authz failure, > rather than a 403. Doesn't ErrorDocument work? Regards, Yann.

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