Re: [Bug 57771] cleanup_script uses incorrect connection ID

[Jeff Trawick]

On Tue, May 10, 2016 at 4:57 PM, Eric Covener  wrote:

> Can I entice anyone else into looking at this PR?  I think I am
> missing the boat entirely.
>

What's the deal?  Pear-flavored drink in return?


>
> My last unwritten thought here was that it might be best to grab the
> pid before returning.
>
> -- Forwarded message --
> From:  
> Date: Wed, Apr 27, 2016 at 8:41 AM
> Subject: [Bug 57771] cleanup_script uses incorrect connection ID
> To: b...@httpd.apache.org
>
>
> https://bz.apache.org/bugzilla/show_bug.cgi?id=57771
>
> --- Comment #8 from Nick Warne  ---
> (In reply to Eric Covener from comment #7)
> > > 4) Thread #1 puts request A to sleep while it waits for the CGI.
> >
> > This bit doesn't make sense to me, but maybe someone else can clarify.
>
> FYI Eric, I see the issue on my NRTG page, which uses a lot of #flastmod.
> This
> small patch totally fixes it up, and I have to apply it manually each new
> apache release.
>
> Nick
>
> --
> You are receiving this mail because:
> You are the assignee for the bug.
>
> -
> To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
> For additional commands, e-mail: bugs-h...@httpd.apache.org
>
>
>
> --
> Eric Covener
> cove...@gmail.com
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: svn commit: r1736510 - /httpd/httpd/branches/2.4.x/STATUS

[Jeff Trawick]

On Tue, Mar 29, 2016 at 12:22 PM, Yann Ylavic  wrote:

> On Thu, Mar 24, 2016 at 10:23 PM,   wrote:
> > Author: trawick
> > Date: Thu Mar 24 21:23:00 2016
> > New Revision: 1736510
> >
> > URL: http://svn.apache.org/viewvc?rev=1736510=rev
> > Log:
> > HTTP_BAD_GATEWAY -> MODSSL_ERROR_BAD_GATEWAY
> >
> > Modified:
> > httpd/httpd/branches/2.4.x/STATUS
> >
> > +  *) mod_ssl: Return 502 instead of 500 when SSL peer check or
> > + proxy_post_handshake hook fails.
> > + Trunk patch: r1645529 (works)
> > + 2.4.x patch which adds CHANGES:
> https://emptyhammock.com/media/downloads/r1645529-to-2.4.x.txt
> > + +1: trawick
>
> In 2.4.x (not trunk), ssl_io_filter_error() seems to finally create an
> HTTP_BAD_REQUEST error bucket for the MODSSL_ERROR_BAD_GATEWAY case,
> shouldn't we also backport r1416589?
>

Something is happening in trunk that causes 500 to be returned when an
error is returned in that area of code.  I'll try to debug that soon, as
the answer for further trunk sync depends on which part of trunk is
resulting in 500 :)

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: svn commit: r1736217 - in /httpd/httpd/trunk/include: ap_hooks.h ap_mmn.h

[Jeff Trawick]

On Thu, Mar 24, 2016 at 5:56 AM, Ruediger Pluem  wrote:

>
>
> On 03/22/2016 06:38 PM, yla...@apache.org wrote:
> > Author: ylavic
> > Date: Tue Mar 22 17:38:20 2016
> > New Revision: 1736217
> >
> > URL: http://svn.apache.org/viewvc?rev=1736217=rev
> > Log:
> > core: Add missing AP_IMPLEMENT_OPTIONAL_HOOK_RUN_FIRST.
> >
> > Modified:
> > httpd/httpd/trunk/include/ap_hooks.h
> > httpd/httpd/trunk/include/ap_mmn.h
> >
> > Modified: httpd/httpd/trunk/include/ap_hooks.h
>
> > Modified: httpd/httpd/trunk/include/ap_mmn.h
> > URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/include/ap_mmn.h?rev=1736217=1736216=1736217=diff
> >
> ==
> > --- httpd/httpd/trunk/include/ap_mmn.h (original)
> > +++ httpd/httpd/trunk/include/ap_mmn.h Tue Mar 22 17:38:20 2016
> > @@ -518,6 +518,7 @@
> >   * ap_mpm_register_poll_callback_timeout and
> >   * ap_mpm_unregister_poll_callback. Add
> >   * AP_MPMQ_CAN_POLL.
> > + * 20160315.1 (2.5.0-dev)  Add AP_IMPLEMENT_OPTIONAL_HOOK_RUN_FIRST.
> >   */
> >
> >  #define MODULE_MAGIC_COOKIE 0x41503235UL /* "AP25" */
> >
> >
> >
>
> You forgot the real bump :-)
>

Remembering to do the real bump is the exception :)

Maybe we need a commit hook???


>
> Regards
>
> Rüdiger
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Status for 2.4.20

[Jeff Trawick]

On Wed, Mar 23, 2016 at 6:56 AM, Jim Jagielski  wrote:

> Let's see: I recalled the vote for 2.4.19 because of a
> single issue, basically related to a missing few lines in
> a file which prevented building on Win. Nice, easy, simple
> fix.
>
> Now it appears that a slew of "fixes" related to Win have
> been applied which, according to some, makes the whole build-
> on-Win situation much much worse.
>
> Now I have no idea what the status of HEAD for 2.4 is and,
> as a result, we are delaying the T and eventual release of
> 2.4.19/20. All because a 4-line fix turned into a master-refactor
> at the last minute.
>
>
Slightly off-topic: 2.4.x HEAD builds fine and serves pages with VS 2012
using the cmake build.  (I was initially sidetracked by the need for a
higher level of nghttp2 to fix their Win32 linkage problem in APIs we
didn't use last time I built on Windows, then by trunk build problems.)


I am tempted to revert 2.4 back...
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Need hints from those building mod_http2 and mod_proxy_http2 on Windows

[Jeff Trawick]

On Tue, Mar 22, 2016 at 6:37 PM, Jeff Trawick <traw...@gmail.com> wrote:

> On Tue, Mar 22, 2016 at 6:31 PM, Jacob Champion <champio...@gmail.com>
> wrote:
>
>> On 03/22/2016 03:11 PM, Jeff Trawick wrote:
>> > What version of nghttp2 are you using?
>> > Are you using the cmake build for httpd?
>>
>> I'm not currently in Windows to be able to check for sure, but I
>> *believe* I'm running nghttp2 1.8.0.
>>
>> > FWIW I just found that I needed nghttp2 >= 1.4.0 on Windows to fix bad
>> > linkage in nghttp2 functions that mod_http2 didn't use when I built
>> > before.  (not related to cmake)
>> >
>> > After resolving that I now see a bunch of unresolved symbols with
>> > mod_proxy_http2.  From the number of symbols and the type there seems to
>> > be a couple of issues in the httpd CMakeLists.txt file.  I can hopefully
>> > look at that early tomorrow a.m.
>>
>> The CMake/mod_proxy_http2 stuff came up before [1]. I didn't hear back
>> from Bill on how his CMake port was going, but I ended up working on one
>> in parallel:
>>
>> https://github.com/jchampio/httpd/commits/dev/cmake-http2
>>
>> Caveat: I haven't taken a look at that patchset in three weeks, or tried
>> to rebase onto latest. I hope it's still potentially useful for you?
>>
>> --Jacob
>>
>> [1]
>>
>> http://mail-archives.apache.org/mod_mbox//httpd-dev/201602.mbox/%3CCAGu%3Du8gSex0%2B4KXfmy_rYCdcB-_TOfb-aZ1%3DrhBihYePx%3D8Tug%40mail.gmail.com%3E
>
>
> Yes, that's useful.  In the short term it makes it easy to tell that
> mod_proxy_http2 simply does not build/run on Windows at all and needs to be
> yanked out of the CMake build for 2.4.x until it does, since it breaks the
> build.
>

I can't stop being an idiot, I'm afraid.  It is in the trunk build, not
2.4.x; let me switch source trees again :)


>
> I hope that I or someone else has time to work through your fixes before
> long.
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Need hints from those building mod_http2 and mod_proxy_http2 on Windows

[Jeff Trawick]

On Tue, Mar 22, 2016 at 6:31 PM, Jacob Champion <champio...@gmail.com>
wrote:

> On 03/22/2016 03:11 PM, Jeff Trawick wrote:
> > What version of nghttp2 are you using?
> > Are you using the cmake build for httpd?
>
> I'm not currently in Windows to be able to check for sure, but I
> *believe* I'm running nghttp2 1.8.0.
>
> > FWIW I just found that I needed nghttp2 >= 1.4.0 on Windows to fix bad
> > linkage in nghttp2 functions that mod_http2 didn't use when I built
> > before.  (not related to cmake)
> >
> > After resolving that I now see a bunch of unresolved symbols with
> > mod_proxy_http2.  From the number of symbols and the type there seems to
> > be a couple of issues in the httpd CMakeLists.txt file.  I can hopefully
> > look at that early tomorrow a.m.
>
> The CMake/mod_proxy_http2 stuff came up before [1]. I didn't hear back
> from Bill on how his CMake port was going, but I ended up working on one
> in parallel:
>
> https://github.com/jchampio/httpd/commits/dev/cmake-http2
>
> Caveat: I haven't taken a look at that patchset in three weeks, or tried
> to rebase onto latest. I hope it's still potentially useful for you?
>
> --Jacob
>
> [1]
>
> http://mail-archives.apache.org/mod_mbox//httpd-dev/201602.mbox/%3CCAGu%3Du8gSex0%2B4KXfmy_rYCdcB-_TOfb-aZ1%3DrhBihYePx%3D8Tug%40mail.gmail.com%3E


Yes, that's useful.  In the short term it makes it easy to tell that
mod_proxy_http2 simply does not build/run on Windows at all and needs to be
yanked out of the CMake build for 2.4.x until it does, since it breaks the
build.

I hope that I or someone else has time to work through your fixes before
long.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Need hints from those building mod_http2 and mod_proxy_http2 on Windows

[Jeff Trawick]

What version of nghttp2 are you using?
Are you using the cmake build for httpd?


FWIW I just found that I needed nghttp2 >= 1.4.0 on Windows to fix bad
linkage in nghttp2 functions that mod_http2 didn't use when I built before.
 (not related to cmake)

After resolving that I now see a bunch of unresolved symbols with
mod_proxy_http2.  From the number of symbols and the type there seems to be
a couple of issues in the httpd CMakeLists.txt file.  I can hopefully look
at that early tomorrow a.m.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: fate of mod_lbmethod_rr (was: Re: [VOTE] Release Apache httpd 2.4.19 as GA)

[Jeff Trawick]

On Tue, Mar 22, 2016 at 5:03 PM, William A Rowe Jr <wr...@rowe-clan.net>
wrote:

> On Tue, Mar 22, 2016 at 3:38 PM, Jeff Trawick <traw...@gmail.com> wrote:
>
>> On Tue, Mar 22, 2016 at 3:55 PM, William A Rowe Jr <wr...@rowe-clan.net>
>> wrote:
>>
>>> Can anyone get mod_lbmethod_rr.c to build?
>>>
>>
>> That's funny actually.  The very first version README.cmake in trunk says
>> that mod_lbmethod_rr.c doesn't build on Windows
>>
>
>  When I added the .dsp, it certainly did build.  --enable-mods=all should
> be
> triggering the build of those sources.
>
> I think this illustrates that we have played fast and loose with something
> that
> 1. is a public API, 2. not experimental, and 3. was illustrated with an
> example
> that has been frequently broken by Major ABI changes.
>
> If devs want to promote an API and then continuously break ABI on trunk,
> I'm way beyond arguing with such individuals.  Just a few choice examples
> which had necessitated major MMN bumps that did not receive one...
>
> http://svn.apache.org/viewvc?view=revision=1560081
> http://svn.apache.org/viewvc?view=revision=1477649 (no
> bitwise-alignment assurance)
> http://svn.apache.org/viewvc?view=revision=1436919 (no
> bitwise-alignment assurance)
>
> However, this module appears to have been broken prior to 2.4.1 GA with
> this
> at least this commit...
> http://svn.apache.org/viewvc?view=revision=1209958
> ... which tells me it is simply an abandoned example.
>
> I propose we remove it from 2.4.x branch and trunk, rather than pretending
> we have maintained it?
>

+1 for removing from 2.4.x branch

no arguments here if someone actually wants it to hang around in trunk, but
I don't actually know if anybody cares so no vote on trunk ATM...

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release Apache httpd 2.4.19 as GA

[Jeff Trawick]

On Tue, Mar 22, 2016 at 3:55 PM, William A Rowe Jr 
wrote:

> Can anyone get mod_lbmethod_rr.c to build?
>

That's funny actually.  The very first version README.cmake in trunk says
that mod_lbmethod_rr.c doesn't build on Windows, yet the only build support
I can find for that module for any platform is in the legacy Windows build
system.  I guess the legacy build spews some error messages and continues
on with the next module?

Meanwhile the proverbial dog is actively chewing on my homework (can't get
past unresolved references in mod_http2 build -- nghttp2 symbols, not the
mod_http2 symbols discussed in this thread) so I'll forget I said anything
about trying to build mod_lbmethod_rr, as there is So Little Time.



> I'm seeing 'name' : is not a member of 'proxy_balancer' errors,
> as well as ap_proxy_retry_worker() undefined (converted into
> an optional function, perhaps?)
>
> On Mon, Mar 21, 2016 at 12:37 PM, Jim Jagielski  wrote:
>
>> The pre-release test tarballs for Apache httpd 2.4.19 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.19 GA.
>>
>> [ ] +1: Good to go
>> [ ] +0: meh
>> [ ] -1: Danger Will Robinson. And why.
>>
>> Vote will last the normal 72 hrs.
>>
>> NOTE: The *-deps are only there for convenience.
>>
>> Thx!
>>
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release Apache httpd 2.4.19 as GA

[Jeff Trawick]

On Tue, Mar 22, 2016 at 3:55 PM, William A Rowe Jr 
wrote:

> Can anyone get mod_lbmethod_rr.c to build?
>

I guess I'll try soon with cmake on Windows, once prereqs are built and I
add a line or two to CMakeLists.txt for that module :)

(I'm backpedaling to trunk from 2.4.19 after seeing a 2.4.19 mod_http2
build error.)


> I'm seeing 'name' : is not a member of 'proxy_balancer' errors,
> as well as ap_proxy_retry_worker() undefined (converted into
> an optional function, perhaps?)
>
> On Mon, Mar 21, 2016 at 12:37 PM, Jim Jagielski  wrote:
>
>> The pre-release test tarballs for Apache httpd 2.4.19 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.19 GA.
>>
>> [ ] +1: Good to go
>> [ ] +0: meh
>> [ ] -1: Danger Will Robinson. And why.
>>
>> Vote will last the normal 72 hrs.
>>
>> NOTE: The *-deps are only there for convenience.
>>
>> Thx!
>>
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: svn commit: r1736070 - /httpd/httpd/branches/2.4.x/modules/ssl/mod_ssl_openssl.h

[Jeff Trawick]

On Mon, Mar 21, 2016 at 1:19 PM,  wrote:

> Author: jim
> Date: Mon Mar 21 17:19:53 2016
> New Revision: 1736070
>
> URL: http://svn.apache.org/viewvc?rev=1736070=rev
> Log:
> ??
>
> Removed:
> httpd/httpd/branches/2.4.x/modules/ssl/mod_ssl_openssl.h
>
>
Something weird is happening in your tree ;)  This file is required.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Plan for T of 2.4.19

[Jeff Trawick]

On Mon, Mar 21, 2016 at 11:40 AM, Jan Ehrhardt  wrote:

> Jim Jagielski in gmane.comp.apache.devel (Mon, 21 Mar 2016 10:55:52
> -0400):
> >UPDATE: I plan to T at ~1pm Eastern.
>
> Will mod_fcgid be part of 2.4.19?
>
> Jan
>
>
mod_fcgid continues to be a separately-released component.

I just noticed that now there are two unreleased fixes in CHANGES-FCGID.
I'd be excited about doing another mod_fcgid release (first in a long
while) if anyone has time/energy to see if there's any low-hanging fruit to
be addressed first.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: "D modules/ssl/mod_ssl_openssl.h"

[Jeff Trawick]

On Mon, Mar 21, 2016 at 8:32 AM, Yann Ylavic <ylavic@gmail.com> wrote:

> On Mon, Mar 21, 2016 at 1:25 PM, Jeff Trawick <traw...@gmail.com> wrote:
> > On Mon, Mar 21, 2016 at 8:12 AM, Jeff Trawick <traw...@gmail.com> wrote:
> >>
> >> I just saw this disappear from 2.4.x; if you know what the cause is, let
> >> me know.  Otherwise I'll figure it out "soon".
> >
> >
> > My svn knowledge fails me...
> >
> > This listing of when I added the file says (Current path doesn't exist
> after
> > revision 1735946)
> >
> >
> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/ssl/mod_ssl_openssl.h?view=log=1735910
> >
> > This doesn't mention the file, although that's supposedly the last
> revision
> > with the file:
> >
> > http://svn.apache.org/viewvc?view=revision=1735946
> >
> > I'll add it again.  I don't know what to do differently :(
>
> Maybe:
> $ cd modules/ssl
> $ svn merge -c -1735947
> https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x/modules/ssl/
> ?
>
> It seemed to have been unintentional in r1735947...
>

Oh, that even shows it deleted mod_ssl_openssl.h:
http://svn.apache.org/viewvc?view=revision=1735947

When I saw the message "Current path doesn't exist after revision 1735946"
I should have looked at 1735947, not 1735946 (

Thanks!!!

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: svn commit: r1735960 - /httpd/httpd/branches/2.4.x/STATUS

[Jeff Trawick]

On Mon, Mar 21, 2016 at 8:25 AM,  wrote:

> Author: ylavic
> Date: Mon Mar 21 12:25:48 2016
> New Revision: 1735960
>
> URL: http://svn.apache.org/viewvc?rev=1735960=rev
> Log:
> Vote, promote.
>
> Modified:
> httpd/httpd/branches/2.4.x/STATUS
>
> Modified: httpd/httpd/branches/2.4.x/STATUS
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1735960=1735959=1735960=diff
>
> ==
> --- httpd/httpd/branches/2.4.x/STATUS (original)
> +++ httpd/httpd/branches/2.4.x/STATUS Mon Mar 21 12:25:48 2016
> @@ -112,6 +112,14 @@ RELEASE SHOWSTOPPERS:
>  PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
>[ start all new proposals below, under PATCHES PROPOSED. ]
>
> +  *) DOCUMENT_ARGS, set by mod_include to represent args to SSI document;
> + unlike UNESCAPED_QUERY_STRING, not shell-escaped
> + trunk patch: r1734817, r1734955, r1734989 (but version compat and
> CHANGES
> +  need to be manipulated)
> + 2.4.x patch:
> https://emptyhammock.com/media/downloads/DOCUMENT_ARGS-to-2.4.x.txt
> + +1: trawick, jim, ylavic
> + ylavic: The second CHANGES entry added in the patch should not be
> merged...
>

Whoops, I'll merge this now and watch out for that.

Thanks!


> +
>
>  PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>[ New proposals should be added at the end of the list ]
> @@ -161,12 +169,6 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>   updated patch with APLOGNOs by merging 1735931,1735935 from trunk
>   updated patch with APLOGNOs by merging 1735942 from trunk
>
> -  *) DOCUMENT_ARGS, set by mod_include to represent args to SSI document;
> - unlike UNESCAPED_QUERY_STRING, not shell-escaped
> - trunk patch: r1734817, r1734955, r1734989 (but version compat and
> CHANGES
> -  need to be manipulated)
> - 2.4.x patch:
> https://emptyhammock.com/media/downloads/DOCUMENT_ARGS-to-2.4.x.txt
> - +1: trawick, jim
>
>  PATCHES/ISSUES THAT ARE BEING WORKED
>
>
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: "D modules/ssl/mod_ssl_openssl.h"

[Jeff Trawick]

On Mon, Mar 21, 2016 at 8:12 AM, Jeff Trawick <traw...@gmail.com> wrote:

> I just saw this disappear from 2.4.x; if you know what the cause is, let
> me know.  Otherwise I'll figure it out "soon".
>

My svn knowledge fails me...

This listing of when I added the file says (*Current path doesn't exist
after revision 1735946*)

http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/ssl/mod_ssl_openssl.h?view=log=1735910

This doesn't mention the file, although that's supposedly the last revision
with the file:

http://svn.apache.org/viewvc?view=revision=1735946

I'll add it again.  I don't know what to do differently :(


>
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

"D modules/ssl/mod_ssl_openssl.h"

[Jeff Trawick]

I just saw this disappear from 2.4.x; if you know what the cause is, let me
know.  Otherwise I'll figure it out "soon".

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: svn commit: r1734396 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS modules/ssl/mod_ssl.c

[Jeff Trawick]

On Fri, Mar 18, 2016 at 1:19 PM, Yann Ylavic <ylavic@gmail.com> wrote:

> On Fri, Mar 18, 2016 at 5:06 PM, Jeff Trawick <traw...@gmail.com> wrote:
> > On Thu, Mar 10, 2016 at 7:31 AM, <yla...@apache.org> wrote:
> >>
> >> Author: ylavic
> >> Date: Thu Mar 10 12:31:13 2016
> >> New Revision: 1734396
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1734396=rev
> >> Log:
> >> Merge r1734006 from trunk:
> >>
> >> mod_ssl: Don't lose track of the SSL context if the
> >> ssl_run_pre_handshake()
> >> hook returns an error.
> >
> >
> > The ssl_run_pre_handshake() hook doesn't exist in the 2.4.x branch.  I
> would
> > rather like it to exist there and will propose so after some testing,
> but it
> > isn't yet clear that the CHANGES entry will make sense for httpd 2.4.19.
> > (We'll see.)
>
> I think the backport worth it because in 2.4.x like in trunk, we could
> also (unlikely) fail in SSL_set_session_id_context(), and likewise
> lose track of sslconn->ssl.
>
> Maybe s/ssl_run_pre_handshake/SSL_set_session_id_context/ in CHANGES?
>

+1

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: svn commit: r1734396 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS modules/ssl/mod_ssl.c

[Jeff Trawick]

On Thu, Mar 10, 2016 at 7:31 AM,  wrote:

> Author: ylavic
> Date: Thu Mar 10 12:31:13 2016
> New Revision: 1734396
>
> URL: http://svn.apache.org/viewvc?rev=1734396=rev
> Log:
> Merge r1734006 from trunk:
>
> mod_ssl: Don't lose track of the SSL context if the ssl_run_pre_handshake()
> hook returns an error.
>

The ssl_run_pre_handshake() hook doesn't exist in the 2.4.x branch.  I
would rather like it to exist there and will propose so after some testing,
but it isn't yet clear that the CHANGES entry will make sense for httpd
2.4.19.  (We'll see.)


>
> Submitted by: minfrin
> Reviewed by: minfrin, jim, ylavic
> Backported by: ylavic
>
> Modified:
> httpd/httpd/branches/2.4.x/   (props changed)
> httpd/httpd/branches/2.4.x/CHANGES
> httpd/httpd/branches/2.4.x/STATUS
> httpd/httpd/branches/2.4.x/modules/ssl/mod_ssl.c
>
> Propchange: httpd/httpd/branches/2.4.x/
>
> --
> --- svn:mergeinfo (original)
> +++ svn:mergeinfo Thu Mar 10 12:31:13 2016
> @@ -2,4 +2,4 @@
>  /httpd/httpd/branches/2.4.17-protocols-http2:1701609-1705681
>  /httpd/httpd/branches/revert-ap-ldap:1150158-1150173
>  /httpd/httpd/branches/wombat-integration:723609-723841
>
> -/httpd/httpd/trunk:1200475,1200478,1200482,1200491,1200496,1200513,1200550,1200556,1200580,1200605,1200612,1200614,1200639,1200646,1200656,1200667,1200679,1200699,1200702,1200955,1200957,1200961,1200963,1200968,1200975,1200977,1201032,1201042,120,1201194,1201198,1201202,1201443,1201450,1201460,1201956,1202236,1202453,1202456,1202886,1203400,1203491,1203632,1203714,1203859,1203980,1204630,1204968,1204990,1205061,1205075,1205379,1205885,1206291,1206472,1206587,1206850,1206940,1206978,1207719,1208753,1208835,1209053,1209085,1209417,1209432,1209461,1209601,1209603,1209618,1209623,1209741,1209754,1209766,1209776,1209797-1209798,1209811-1209812,1209814,1209908,1209910,1209913,1209916-1209917,1209947,1209952,1210067,1210080,1210120,1210124,1210130,1210148,1210219,1210221,1210252,1210284,1210336,1210378,1210725,1210892,1210951,1210954,1211351-1211352,1211364,1211490,1211495,1211528,1211663,1211680,1212872,1212883,1213338,1213380-1213381,1213391,1213399,1213567,1214003,1214005,1214015,12
>
>  
> 15514,1220462,1220467,1220493,1220524,1220570,1220768,1220794,1220826,1220846,1221205,1221292,1222335,1222370,1222473,1222915,1222917,1222921,1222930,1223048,1225060,1225197-1225199,1225223,1225380,1225476,1225478,1225791,1225795-1225796,1226339,1226375,1227910,1228700,1228816,1229024,1229059,1229099,1229116,1229134,1229136,1229930,1230286,1231255,1231257,1231442,1231446,1231508,1231510,1231518,1232575,1232594,1232630,1232838,1234180,1234297,1234479,1234511,1234565,1234574,1234642-1234643,1234876,1234899,1235019,1236122,1236701,1237407,1238545,1238768,1239029-1239030,1239071,1239565,1240315,1240470,1240778,1241069,1241071,1242089,1242798,1242967,1243176,1243246,1243797,1243799,1244211,1245717,1290823,1290835,1291819-1291820,1291834,1291840,1292043,1293405,1293534-1293535,1293658,1293678,1293708,1294306,1294349,1294356,1294358,1294372,1294471,1297560,1299718,1299786,1300766,130,1301725,1302444,1302483,1302653,1302665,1302674,1303201,1303435,1303827,1304087,1304874-1304875,1305167
>
>  
> ,1305586,1306350,1306409,1306426,1306841,1307790,1308327,1308459,1309536,1309567,1311468,1324760,1325218,1325227,1325250,1325265,1325275,1325632,1325724,1326980,1326984,1326991,1327689,1328325-1328326,1328339,1328345,1328950,1330189,1330964,1331110,1331115,1331942,1331977,1332378,1333969,1334343,1335882,1337344,1341906,1341913,1343085,1343087,1343094,1343099,1343109,1343935,1345319,1345329,1346905,1347980,1348036,1348653,1348656,1348660,1349905,1351012-1351020,1351071-1351072,1351074,1351737,1352047,1352534,1352909-1352912,1357685,1358061,1359057,1359881,1359884,1361153,1361298,1361766,1361773,1361778,1361784,1361791-1361792,1361801,1361803,1362020,1362538,1362707,1363035,1363183,1363186,1363312,1363440,1363557,1363589,1363829,1363832,1363836-1363837,1363853,1364133,1364138,1364229,1364601,1364695,1365001,1365020,1365029,1365479,1366319,1366344,1366621,1367778,1367819,1368053,1368058,1368094,1368121,1368131,1368393,1368396,1369419,1369568,1369604,1369618,1369904,1369995,136,1370
>
>  
> 

Re: svn commit: r1734947 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/core.xml include/http_core.h server/core.c server/util_script.c

[Jeff Trawick]

Feedback requested below on a couple of issues...

On Mon, Mar 14, 2016 at 11:42 AM,  wrote:

> Author: trawick
> Date: Mon Mar 14 15:42:45 2016
> New Revision: 1734947
>
> URL: http://svn.apache.org/viewvc?rev=1734947=rev
> Log:
> Add CGIVar directive for configuring REQUEST_URI behavior
>
> The goal is to use this one directive to handle any configurable
> CGI variable behavior; only one CGI variable is supported initially.
>
> Modified:
> httpd/httpd/trunk/CHANGES
> httpd/httpd/trunk/docs/manual/mod/core.xml
> httpd/httpd/trunk/include/http_core.h
> httpd/httpd/trunk/server/core.c
> httpd/httpd/trunk/server/util_script.c
>
> ...


>
> Modified: httpd/httpd/trunk/include/http_core.h
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/include/http_core.h?rev=1734947=1734946=1734947=diff
>
> ==
> --- httpd/httpd/trunk/include/http_core.h (original)
> +++ httpd/httpd/trunk/include/http_core.h Mon Mar 14 15:42:45 2016
> @@ -673,6 +673,9 @@ typedef struct {
>
>  unsigned int qualify_redirect_url :2;
>  ap_expr_info_t  *expr_handler; /* forced with SetHandler */
> +
> +/** Table of rules for building CGI variables, NULL if none
> configured */
> +apr_hash_t *cgi_var_rules;
>

Any concerns with forcing the module/core/whatever to have to check if the
table has been created before seeing if it has a rule for a particular
variable?


>  } core_dir_config;
>
>  /* macro to implement off by default behaviour */
>
> Modified: httpd/httpd/trunk/server/core.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/core.c?rev=1734947=1734946=1734947=diff
>
> ==
> --- httpd/httpd/trunk/server/core.c (original)
> +++ httpd/httpd/trunk/server/core.c Mon Mar 14 15:42:45 2016
> @@ -420,6 +420,15 @@ static void *merge_core_dir_configs(apr_
>
>  conf->cgi_pass_auth = new->cgi_pass_auth != AP_CGI_PASS_AUTH_UNSET ?
> new->cgi_pass_auth : base->cgi_pass_auth;
>
> +if (new->cgi_var_rules) {
> +if (!conf->cgi_var_rules) {
> +conf->cgi_var_rules = new->cgi_var_rules;
> +}
> +else {
> +conf->cgi_var_rules = apr_hash_overlay(a, new->cgi_var_rules,
> conf->cgi_var_rules);
> +}
> +}
> +
>  AP_CORE_MERGE_FLAG(qualify_redirect_url, conf, base, new);
>
>  return (void*)conf;
> @@ -1872,6 +1881,31 @@ static const char *set_cgi_pass_auth(cmd
>  return NULL;
>  }
>
> +static const char *set_cgi_var(cmd_parms *cmd, void *d_,
> +   const char *var, const char *rule_)
> +{
> +core_dir_config *d = d_;
> +char *rule = apr_pstrdup(cmd->pool, rule_);
> +
> +ap_str_tolower(rule);
> +
> +if (!strcmp(var, "REQUEST_URI")) {
> +if (strcmp(rule, "current-uri") && strcmp(rule, "original-uri")) {
> +return "Valid rules for REQUEST_URI are 'current-uri' and
> 'original-uri'";
> +}
> +}
> +else {
> +return apr_pstrcat(cmd->pool, "Unrecognized CGI variable: \"",
> +   var, "\"", NULL);
>

I can see letting third-party modules use this directive for their own
purposes, which requires ignoring variables/rules we don't know about and
simply storing them in the table.  For the time being this refuses any
unexpected variables/rules; that could be loosened up later if desired.
But the possibility has some effect on the choice of rule representation --
flexible character string (current) vs. some enumerated value (more
efficient).  (Aside from letting third-party modules play without custom
code in httpd, it also simplifies the httpd implementation to pass through
anything.  That's what happens essentially with "SetEnvIf Request_URI .
proxy-fcgi-pathinfo".)

Any thoughts?



> +}
> +
> +if (!d->cgi_var_rules) {
> +d->cgi_var_rules = apr_hash_make(cmd->pool);
> +}
> +apr_hash_set(d->cgi_var_rules, var, APR_HASH_KEY_STRING, rule);
> +return NULL;
> +}
> +
>  static const char *set_qualify_redirect_url(cmd_parms *cmd, void *d_, int
> flag)
>  {
>  core_dir_config *d = d_;
> @@ -4565,6 +4599,8 @@ AP_INIT_TAKE12("LimitInternalRecursion",
>  AP_INIT_FLAG("CGIPassAuth", set_cgi_pass_auth, NULL, OR_AUTHCFG,
>   "Controls whether HTTP authorization headers, normally
> hidden, will "
>   "be passed to scripts"),
> +AP_INIT_TAKE2("CGIVar", set_cgi_var, NULL, OR_FILEINFO,
> +  "Controls how some CGI variables are set"),
>  AP_INIT_FLAG("QualifyRedirectURL", set_qualify_redirect_url, NULL,
> OR_FILEINFO,
>   "Controls whether the REDIRECT_URL environment variable is
> fully "
>   "qualified"),
>
> Modified: httpd/httpd/trunk/server/util_script.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/util_script.c?rev=1734947=1734946=1734947=diff
>
> 

configuring alternate algorithms for CGI variables (yet again?)

[Jeff Trawick]

Synopsis:

CGIVariable variable keyword-applicable-to-variable

e.g.,

CGIVariable REQUEST_URI from-active-request|from-request-line

(Please oh please think of a better directive name :) )

from-active-request:  REQUEST_URI will be set from the active request
(possibly a subrequest).
from-request-line (default):  REQUEST_URI will be set from the original
request line received from the client.

This kind of setting would be part of core's request_config, and would be
consulted as appropriate by different code bundled with httpd
(ap_add_cgi_vars(), mod_proxy_FOO, etc.) or even third-party modules
(mod_xSGI), like the CGIPassAuth directive.

The problem at hand: Make REQUEST_URI in a script invoked via SSI represent
the script invocation, not the original request.  It worked this way in
very early 2.0.x for a while, until https://archive.apache.org/gnats/7580
which restored the 1.3 behavior.  The current value in httpd is a pain for
a particular customer app that can be used with httpd 2.4 or with a
different web server.  (FWIW, ssl_var_lookup("REQUEST_URI") uses r->uri; I
didn't even know it cared.)

Generally: An more obvious variable that could use such configuration is
PATH_INFO; this is implemented (inconsistently) in multiple proxy backends,
and configured using an "envvar" that isn't effective if you do the obvious
thing, SetEnv.  While PATH_INFO is out of scope for me for the moment, I'd
like to control how REQUEST_URI is set in a manner that is extensible to
other CGI variables in the future.

Thoughts?

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: ABI report

[Jeff Trawick]

On Mon, Feb 8, 2016 at 12:57 PM, William A Rowe Jr 
wrote:

> This is excellent, thanks for the effort!
>
> You should note that there was no binary compatibility between 2.2.x final
> and 2.4.x.  And there will be no binary compatibility between 2.next (3.0?)
> and 2.4.x.  The interesting branches to compare for 2.2.next and 2.4.next
> to anticipate any binary breakage before we release would be in subversion
> under the paths;
>
> http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x
> http://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x
>
> while 2.next (3.0) with binary-breaking changes lives at the path;
> http://svn.apache.org/repos/asf/httpd/httpd/trunk
>
> This looks like a great tool, much appreciated :)
>
> Bill
>
>
> On Sun, Feb 7, 2016 at 2:32 AM, Ponomarenko Andrey <
> andrewponomare...@yandex.ru> wrote:
>
>> Hello,
>>
>> I've started to maintain binary compatibility report for the recent
>> versions of the httpd: http://abi-laboratory.pro/tracker/timeline/httpd/
>>
>> The report is updated every other day. The report for the latest version
>> from git is also there. Hope this helps Linux maintainers to be aware of
>> ABI changes and added/removed symbols.
>>
>> Thank you.
>>
>
>
Perhaps there could be a way to configure a message related to the intended
breakage between 2.2.last and 2.4.first, since that is interesting from an
API migration standpoint.  (Link to
https://httpd.apache.org/docs/2.4/developer/new_api_2_4.html)


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Segfault on graceful reload with OCSP stapling enabled?

[Jeff Trawick]

On Mon, Dec 21, 2015 at 8:09 AM, Micha Lenk  wrote:

> Hi all,
>
> Am 18.12.2015 12:35, schrieb Micha Lenk:
>
>> I am currently observing a httpd segfault that is triggered on my
>> system by every second graceful reload (i.e. SIGUSR1).
>>
>> Unfotunately I won't be able to trace this down before Monday, so this
>> is merely a heads-up for those interested.
>> Is anybody able to reproduce this behavior?
>>
>
> Just for the records, the segfault seems to be caused by a bad patch.
> So sorry for the noise...
>

Thanks for reporting back/glad it is resolved!


>
> Best regards,
> Micha
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Thx and merit

[Jeff Trawick]

On Wed, Oct 14, 2015 at 8:58 AM, Jim Jagielski  wrote:

> The ASF is all about recognizing and rewarding merit. The whole
> "Apache Way" started here, with this project, and httpd has always
> been the sort of "guiding light" and example of how Apache projects
> (should) work.
>
> Inclusion of the HTTP/2 implementation for httpd, especially for
> the 2.4.x branch, is a substantial feather in our cap. But we
> would have been far behind the 8-ball if not for the funding by
> the GSM Association on greenbytes GmbH's mod_h2 work, and for
> the donation of that module to the ASF.
>
> Once again, I'd like to thank them personally!
>

+1!

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Thx and merit

[Jeff Trawick]

On Wed, Oct 14, 2015 at 10:02 AM, Nick Kew  wrote:

> On Wed, 14 Oct 2015 08:58:48 -0400
> Jim Jagielski  wrote:
>
>
> > Once again, I'd like to thank them personally!
>
> +1 to all that, with one small addition.
>
> Apache is about the individuals who participate.  So the
> chief thanks go to Stefan, who is of course now one of us.
> And of course honourable mentions to other developers
> such as your good self.
>
> --
> Nick Kew
>

I almost hate to say this because I don't want to take anything away from
Stefan, but companies sponsoring work are essentially the people behind the
scenes that we never hear about who are open to or are in fact the driving
force for aligning business goals with development that can be shared with
everyone else, sometimes at the risk of having it blow up in their face if
somebody says the wrong thing or someone in the project can't separate
suspected motivation from assessment of utility.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release Apache httpd 2.4.17 as GA

[Jeff Trawick]

On Fri, Oct 9, 2015 at 1:40 PM, Jim Jagielski  wrote:

> The pre-release test tarballs for Apache httpd 2.4.17 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.17 GA.
>
> [ ] +1: Good to go
> [ ] +0: meh
> [ ] -1: Danger Will Robinson. And why.
>
> Vote will last the normal 72 hrs.
>
> NOTE: The *-deps are only there for convenience.
>
> Thx!
>
>
[X] +1: no regression, works with my existing production config with no
apparent problems

On Fedora 22, the only platform where I ran the test suite (latest version
as of yesterday afternoon), I'm getting a bunch of errors for http2 which I
don't see mentioned elsewhere.  I guess they're most likely triggered by
the Perl side of things???

t/modules/http2.t ... 1/52 # Failed test 11 in
t/modules/http2.t at line 174
# Failed test 12 in t/modules/http2.t at line 176
# Failed test 13 in t/modules/http2.t at line 174 fail #2
# Failed test 14 in t/modules/http2.t at line 176 fail #2
# Failed test 15 in t/modules/http2.t at line 162
# Failed test 16 in t/modules/http2.t at line 164
# Failed test 17 in t/modules/http2.t at line 162 fail #2
# Failed test 18 in t/modules/http2.t at line 164 fail #2
# Failed test 19 in t/modules/http2.t at line 174 fail #3
# Failed test 20 in t/modules/http2.t at line 176 fail #3
# Failed test 21 in t/modules/http2.t at line 162 fail #3
# Failed test 22 in t/modules/http2.t at line 164 fail #3
# Failed test 23 in t/modules/http2.t at line 162 fail #4
# Failed test 24 in t/modules/http2.t at line 164 fail #4
# Failed test 25 in t/modules/http2.t at line 162 fail #5
# Failed test 26 in t/modules/http2.t at line 164 fail #5
# Failed test 37 in t/modules/http2.t at line 174 fail #4
# Failed test 38 in t/modules/http2.t at line 176 fail #4
# Failed test 39 in t/modules/http2.t at line 174 fail #5
# Failed test 40 in t/modules/http2.t at line 176 fail #5
# Failed test 41 in t/modules/http2.t at line 162 fail #6
# Failed test 42 in t/modules/http2.t at line 164 fail #6
# Failed test 43 in t/modules/http2.t at line 162 fail #7
# Failed test 44 in t/modules/http2.t at line 164 fail #7
# Failed test 45 in t/modules/http2.t at line 174 fail #6
# Failed test 46 in t/modules/http2.t at line 176 fail #6
# Failed test 47 in t/modules/http2.t at line 162 fail #8
# Failed test 48 in t/modules/http2.t at line 164 fail #8
# Failed test 49 in t/modules/http2.t at line 162 fail #9
# Failed test 50 in t/modules/http2.t at line 164 fail #9
# Failed test 51 in t/modules/http2.t at line 162 fail #10
# Failed test 52 in t/modules/http2.t at line 164 fail #10
t/modules/http2.t ... Failed 32/52 subtests

(no other errors, DAV tests were skipped due to lack of appropriate Perl
module)

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: mod_http2 version number

[Jeff Trawick]

On Thu, Oct 8, 2015 at 8:08 AM, Stefan Eissing <stefan.eiss...@greenbytes.de
> wrote:

> Well, it is used only in one INFO log statement on startup...
>
> There are now several people who participated in early trials if mod_h2
> and gave really useful feedback and found bugs. Without a version number of
> the module being visible in the log somewhere, it would make this kind of
> tests much more difficult.
>
> While the module is experimental, I'd like to continue giving the
> adventurous types early experience versions. That way we can gather useful
> feedback between release cycles.
>

Cool, thanks...  (I guess they'll get a patch to put over 2.4.17, and the
patch will have a modified version.)


>
> Once we leave the experimental mode and merge all tighter to the core,
> this version number becomes meaningless and should go.
>
> //Stefan
>
> > Am 08.10.2015 um 13:59 schrieb Jeff Trawick <traw...@gmail.com>:
> >
> > Can we get rid of this?  The only meaningful version is the httpd
> version.  (I guess mod_ssl still pretends to have a meaningful version
> number.)
> >
> > I could see a potential use of a separate version number in the very
> short term to indicate API breakages in this "experimental" component that
> we couldn't with an MMN Major change, but then the version number has to be
> updated following certain rules and the purpose has to be well described to
> module authors, and module authors mucking with internals of this should be
> following httpd dev closely anyway, at least until it is not experimental.
> >
> > --
> > Born in Roswell... married an alien...
> > http://emptyhammock.com/
> >
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

mod_http2 version number

[Jeff Trawick]

Can we get rid of this?  The only meaningful version is the httpd version.
 (I guess mod_ssl still pretends to have a meaningful version number.)

I could see a potential use of a separate version number in the very short
term to indicate API breakages in this "experimental" component that we
couldn't with an MMN Major change, but then the version number has to be
updated following certain rules and the purpose has to be well described to
module authors, and module authors mucking with internals of this should be
following httpd dev closely anyway, at least until it is not experimental.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: svn commit: r1707161 - in /httpd/httpd/trunk: docs/manual/mod/core.xml include/ap_mmn.h include/http_core.h include/httpd.h server/core.c server/request.c server/util_filter.c

[Jeff Trawick]

On Tue, Oct 6, 2015 at 6:33 PM,  wrote:

> Author: minfrin
> Date: Tue Oct  6 22:33:03 2015
> New Revision: 1707161
>
> URL: http://svn.apache.org/viewvc?rev=1707161=rev
> Log:
> Add the AsyncFilter directive that allows the asynchronous filter
> functionality to be switched off for certain classes of filters.
>
> Modified:
> httpd/httpd/trunk/docs/manual/mod/core.xml
> httpd/httpd/trunk/include/ap_mmn.h
> httpd/httpd/trunk/include/http_core.h
> httpd/httpd/trunk/include/httpd.h
> httpd/httpd/trunk/server/core.c
> httpd/httpd/trunk/server/request.c
> httpd/httpd/trunk/server/util_filter.c
>
> Modified: httpd/httpd/trunk/docs/manual/mod/core.xml
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/core.xml?rev=1707161=1707160=1707161=diff
>
> ==
> --- httpd/httpd/trunk/docs/manual/mod/core.xml (original)
> +++ httpd/httpd/trunk/docs/manual/mod/core.xml Tue Oct  6 22:33:03 2015
> @@ -552,6 +552,32 @@ AllowOverrideList CookieTracking CookieN
>  
>
>  
> +AsyncFilter
> +Set the minimum filter type eligible for asynchronous
> handling
> +AsyncFilter request|connection|network
> +AsyncFilter request
> +server configvirtual
> host
> +Only available from Apache 2.5.0 and
> later.
> +
> +
> +This directive controls the minimum filter levels that are
> eligible
> +for asynchronous handling. This may be necessary to support
> legacy external
> +filters that did not handle meta buckets correctly.
> +
> +If set to "network", asynchronous handling will be limited to
> the network
> +filter only. If set to "connection", all connection and network
> filters
> +will be eligible for asynchronous handling, including
> mod_ssl.
> +If set to "request", all filters will be eligible for
> asynchronous handling.
> +
> +With ProtocolsHonorOrder set to
> on
> +(default), the client ordering does not matter and only the
> ordering
> +in the server settings influences the outcome of the protocol
> +negotiation.
> +
> +
> +
> +
> +
>  CGIMapExtension
>  Technique for locating the interpreter for CGI
>  scripts
>
> Modified: httpd/httpd/trunk/include/ap_mmn.h
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/include/ap_mmn.h?rev=1707161=1707160=1707161=diff
>
> ==
> --- httpd/httpd/trunk/include/ap_mmn.h (original)
> +++ httpd/httpd/trunk/include/ap_mmn.h Tue Oct  6 22:33:03 2015
> @@ -494,6 +494,7 @@
>   * ap_filter_reinstate_brigade() and
>   * ap_filter_should_yield(). Add empty and
> filters to
>   * conn_rec.
> + * 20150222.6 (2.5.0-dev)  Add async_filter to conn_rec.
>   */
>
>  #define MODULE_MAGIC_COOKIE 0x41503235UL /* "AP25" */
> @@ -501,7 +502,7 @@
>  #ifndef MODULE_MAGIC_NUMBER_MAJOR
>  #define MODULE_MAGIC_NUMBER_MAJOR 20150222
>  #endif
> -#define MODULE_MAGIC_NUMBER_MINOR 5 /* 0...n */
> +#define MODULE_MAGIC_NUMBER_MINOR 6 /* 0...n */
>
>  /**
>   * Determine if the server's current MODULE_MAGIC_NUMBER is at least a
>
> Modified: httpd/httpd/trunk/include/http_core.h
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/include/http_core.h?rev=1707161=1707160=1707161=diff
>
> ==
> --- httpd/httpd/trunk/include/http_core.h (original)
> +++ httpd/httpd/trunk/include/http_core.h Tue Oct  6 22:33:03 2015
> @@ -711,6 +711,8 @@ typedef struct {
>
>  apr_array_header_t *protocols;
>  int protocols_honor_order;
> +int async_filter;
> +int async_filter_set:1;
>

"unsigned"  is a better choice for this; I think we fixed all of the signed
bit fields in httpd, some out of necessity IIRC

 } core_server_config;
>
>  /* for AddOutputFiltersByType in core.c */
>
> Modified: httpd/httpd/trunk/include/httpd.h
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/include/httpd.h?rev=1707161=1707160=1707161=diff
>
> ==
> --- httpd/httpd/trunk/include/httpd.h (original)
> +++ httpd/httpd/trunk/include/httpd.h Tue Oct  6 22:33:03 2015
> @@ -1198,6 +1198,9 @@ struct conn_rec {
>
>  /** Hashtable of filters with setaside buckets for write completion */
>  apr_hash_t *filters;
> +
> +/** The minimum level of filter type to allow setaside buckets */
> +int async_filter;
>  };
>
>  struct conn_slave_rec {
>
> Modified: httpd/httpd/trunk/server/core.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/core.c?rev=1707161=1707160=1707161=diff
>
> ==
> --- httpd/httpd/trunk/server/core.c (original)
> +++ 

Re: T of 2.4.17 this week

[Jeff Trawick]

On Tue, Oct 6, 2015 at 7:44 AM, Daniel Gruno  wrote:

> On 10/05/2015 06:35 PM, Daniel Gruno wrote:
> > +1!
> > There's so much new goodness we have to share! :)
> >
> > On 10/5/2015, 5:54:04 PM, Jim Jagielski  wrote:
> >> I propose a T of 2.4.17 this week with a release for next. I
> >> will RM.
> >>
> >> Comments?
> >>
>
> Also, if someone could verify that the tweaks I made to mod_lua makes it
> compile properly on Ubutnu 14.04 (with lua5.2-dev installed), that would
> be super swell!
>
>
The build looks okay here, but I haven't tried any scripts...

VERSION="14.04.3 LTS, Trusty Tahr"

liblua5.2-0:amd64 install
liblua5.2-dev:amd64 install

checking whether to enable mod_lua... checking dependencies
checking for pow in -lm... yes
checking for sqrt in -lm... yes
checking for lua.h in ./include/lua-5.2... no
checking for lua.h in ./include/lua5.2... no
checking for lua.h in ./include/lua52... no
checking for lua.h in ./include... no
checking for lua.h in ./include/lua-5.1... no
checking for lua.h in ./include/lua5.1... no
checking for lua.h in ./include/lua51... no
checking for lua.h in /usr/local/include/lua-5.2... no
checking for lua.h in /usr/local/include/lua5.2... no
checking for lua.h in /usr/local/include/lua52... no
checking for lua.h in /usr/local/include... no
checking for lua.h in /usr/local/include/lua-5.1... no
checking for lua.h in /usr/local/include/lua5.1... no
checking for lua.h in /usr/local/include/lua51... no
checking for lua.h in /usr/include/lua-5.2... no
checking for lua.h in /usr/include/lua5.2... yes
checking for luaL_newstate in -llua5.2... yes
configure: using '-L/usr/lib -llua5.2 -lm' for Lua Library
  setting MOD_INCLUDES to "-I/usr/include/lua5.2"
  setting MOD_LUA_LDADD to "-L/usr/lib -llua5.2 -lm"
checking whether to enable mod_lua... shared
  adding "-I$(top_srcdir)/modules/lua" to INCLUDES

(no compile warnings)

$ ~/inst/24-64/bin/apachectl -M | grep lua
 lua_module (shared)


With regards,
> Daniel.
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: svn commit: r1706637 - /httpd/httpd/trunk/modules/http2/config.m4

[Jeff Trawick]

On Sat, Oct 3, 2015 at 5:32 PM,  wrote:

> Author: trawick
> Date: Sat Oct  3 21:32:56 2015
> New Revision: 1706637
>
> URL: http://svn.apache.org/viewvc?rev=1706637=rev
> Log:
> Follow-up to r1690248:
>
> Fix logic to limit exported symbols in DSO form of mod_http2.
>
> Modified:
> httpd/httpd/trunk/modules/http2/config.m4
>
> Modified: httpd/httpd/trunk/modules/http2/config.m4
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/config.m4?rev=1706637=1706636=1706637=diff
>
> ==
> --- httpd/httpd/trunk/modules/http2/config.m4 (original)
> +++ httpd/httpd/trunk/modules/http2/config.m4 Sat Oct  3 21:32:56 2015
> @@ -174,7 +174,7 @@ See --with-nghttp2 on how to manage non-
>  is usually linked shared and requires loading. ], $http2_objs, , most, [
>  APACHE_CHECK_NGHTTP2
>  if test "$ac_cv_nghttp2" = "yes" ; then
> -if test "x$enable_ssl" = "xshared"; then
> +if test "x$enable_http2" = "xshared"; then
> # The only symbol which needs to be exported is the module
> # structure, so ask libtool to hide everything else:
> APR_ADDTO(MOD_HTTP2_LDADD, [-export-symbols-regex
> http2_module])
>
>
>

This is CTR in the 2.4.x branch, right?  (i.e., can just commit it?)

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: SSLUseStapling: ssl handshake fails until httpd restart

[Jeff Trawick]

On 09/29/2015 04:20 AM, Reindl Harald wrote:

is that by intention?


The default timeout before retrying an error seems to be 10 minutes (see 
http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslstaplingerrorcachetimeout), 
which is pretty excessive.


As far as you recall about the time period before you gave up, was that 
within 10 minutes?




firefox refused to open our adminpanel with the error below until i 
restarted httpd - i suggest the server should retry SSLUseStapling 
when a new client connects and it has failed for whatever reason


SSLUseStapling On

An error occurred during a connection to ***:8443. The OCSP server 
suggests trying again later. (Error code: 
sec_error_ocsp_try_server_later)

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Jeff Trawick]

On 09/04/2015 10:59 AM, Kaspar Brand wrote:

On 02.09.2015 01:54, Jeff Trawick wrote:

On 08/30/2015 02:30 AM, Kaspar Brand wrote:

today's situation, because this assessment misses the fact that with the
current RFC-6066-based implementation, stapling can't fully achieve the
goal of obviating OCSP queries for the clients - all publicly trusted
CAs use hierarchies with at least two tiers these days, so effectively
RFC 6961 support would be needed.

I plead ignorance, but I don't see that "can't fully achieve" is a blocker.

It's not a blocker, sure, but on the other hand, the benefit of enabling
stapling by default isn't that big either - as long as browsers don't
hard-fail when OCSP information isn't available. The "speed, speed,
speed" argument (coming mostly from the browser vendors) isn't too
convincing to me neither, as OCSP replies are usually cached for one
or two days, and the typical user doesn't connect to thousands of
new/different SSL sites per day.


Is there a synopsis of which browsers support it for which types of
certificates?

I don't think so, and it's probably also kind of a moving target. Chrome
"supports" it for DV and OV as well - it will include a status_request
extension in the TLS handshake by default -, but what I meant with
"enforces" is that it won't care if there's no stapled response
(Google's ceterum censeo used to be "Revocation doesn't work", which in
2012 lead to their implementation of CRL sets where the code is public,
but "the process by which they are generated is not",
https://dev.chromium.org/Home/chromium-security/crlsets).

For EV certs, the browser behavior is more uniform, though strict hard
fail enforcement still isn't happening - for testing purposes, try
this experiment: block connections to sr.symcb.com:80 and sr.symcd.com:80,
and point the browser to
https://test-sspev.verisign.com:2443/test-SSPEV-revoked-verisign.html.
With strict revocation checking enforced, no browser should ever render
any content of the "Revoked VeriSign Secure Site Pro with EV Certificate
Test Page" (but most do when revocation information is not available,
although some at least show warnings or downgrade the UI to non-EV).


The motivation for putting it in trunk is so that the next release has
stapling enabled in the default configurations, which essentially means
that in some number of years (2-3?  I dunno) there will be a
faster-growing number of httpd instances that have OCSP stapling enabled.

Ok, if it's about 2.6/3.0, then we're indeed talking of a timeframe of
several years, I assume. What I don't like with this approach in any
case, however, is that we as the devs decide on behalf of the admins,
instead of letting them make an informed decision. I' really arguing
in favor of something like this in httpd-ssl.conf.in:

--- snip ---
#   SSL Engine Switch:
#   Enable/Disable SSL for this virtual host.
SSLEngine on

#  Server Certificate and Private Key:
#  ...
SSLCertificateFile "conf/server.crt"
SSLCertificateKeyFile "conf/server.key"

#  OCSP Stapling:
#  For SSL certificates which include an OCSP responder URI, mod_ssl
#  can include revocation status information for the server's own
#  certificate in the TLS handshake. Enabling this option requires
#  outgoing connectivity to the CA's OCSP responder (usually running
#  running on port 80, use "openssl x509 -in server.crt -text" to
#  determine the exact URI), so this option is not enabled by default.
#  The responder will be queried with the interval configured
#  via SSLStaplingStandardCacheTimeout. For EV SSL certificates
#  in particular, enabling this option is recommended/useful.
#SSLUseStapling On
--- snip ---

(i.e., move the SSLUseStapling directive closer to the cert settings,
and make people aware of the outgoing connections this will trigger)


Part of what makes the 2.4.x tangent is confusing is that sometimes your
objections seem to be qualified on the assumption that 2.4.x would be
updated.  Can we please drop 2.4.x from this conversation?

Will do, yes. When trunk becomes 2.6/3.0 one day (and a GA release), the
basic question remains, though: is it acceptable that configuring an SSL
certificate potentially triggers outgoing OCSP requests in mod_ssl,
without having been explicitly instructed to do so by an admin? My view
is still the same as in November 2014: admins should opt in for this
feature, not be forced to opt out.


   It's also for this reason that I'm not in favor of a global
"SSLUseStapling On", it should really be configured on a per-vhost basis.

I don't follow.  What does that help?  With which attack vector does
that improve the situation?

The point I was trying to make is that stapling is a per-certificate
feature (not a global one like SSLRandomSeed, SSLSessionCache etc.), so
it would be best if the admin becomes aware of it when configuring the cert.


While I find the "n

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Jeff Trawick]

On 08/30/2015 02:30 AM, Kaspar Brand wrote:

On 28.08.2015 19:27, Jeff Trawick wrote:

For one, it is appropriate for the default config is there to enable
practices which are reasonable in most situations, and OCSP Stapling is
widely accepted as an appropriate feature for HTTP servers to enable.

I have some doubts whether "widely accepted" is an accurate summary of
today's situation, because this assessment misses the fact that with the
current RFC-6066-based implementation, stapling can't fully achieve the
goal of obviating OCSP queries for the clients - all publicly trusted
CAs use hierarchies with at least two tiers these days, so effectively
RFC 6961 support would be needed.

I plead ignorance, but I don't see that "can't fully achieve" is a blocker.


  And given that the most popular
browser only enforces revocation checking for EV certificates (certainly
less than 10% of all SSL certs out there), the benefit of turning on
stapling for DV/OV certs by default is not so apparent either.


Is there a synopsis of which browsers support it for which types of 
certificates?




What wasn't mentioned in the original RFC [1], and what I'm still
wondering about, is the primary motivation for enabling it on trunk?


The motivation for putting it in trunk is so that the next release has 
stapling enabled in the default configurations, which essentially means 
that in some number of years (2-3?  I dunno) there will be a 
faster-growing number of httpd instances that have OCSP stapling enabled.


Admins can of course enable it now, but people don't bother until 
something like SSLLabs starts dinging configurations that don't have it on.



  As
I wrote in my reply at that time, changing the default in trunk will
hardly help in getting broader real-world testing results.


For now, it hardly helps.  As we approach a release and start talking 
about it and having alphas and betas, it helps a lot more because more 
than the same 20 people are trying it out.



  If the
plan is to propose a backport to 2.4.x soon afterwards, however, then I
would certainly oppose unless systematic coverage for OCSP stapling is
added to the test framework (enabling a feature by default in a GA
release for which there is not a single test is a no go, IMO).


The point about adding tests is good.

I find this 2.4.x tangent disorienting, but maybe that's just me. (And 
even if 2.4.x default configs were changed, it would affect hardly 
anyone.  The people who build from source and just start using the 
latest configs every time probably aren't in control of many aspects of 
their system anyway.  Building and installing the normal way leaves you 
with the same configuration.)


Part of what makes the 2.4.x tangent is confusing is that sometimes your 
objections seem to be qualified on the assumption that 2.4.x would be 
updated.  Can we please drop 2.4.x from this conversation?





Also, strictly speaking, the default config does not have SSL enabled
anyway, and after manually enabling it OCSP responses won't be fetched
unless a certificate is configured which references an OCSP responder.

It should be worth mentioning that the OCSP URI in a server cert is to
be considered untrusted, as mod_ssl does not validate its own cert at
startup.


I would think that the problem is if the hostname doesn't point where it 
is supposed to point, so the I/O can't be allowed to stall and mod_ssl 
and OpenSSL have to avoid assuming the data is well-formed.  Besides 
that, the admin and the browser own the rest.



  It's also for this reason that I'm not in favor of a global
"SSLUseStapling On", it should really be configured on a per-vhost basis.


I don't follow.  What does that help?  With which attack vector does 
that improve the situation?





While I find the "not make accidental outgoing connections" argument
compelling (though perhaps with a different word than "accidental") the
server already takes actions that cause outgoing connections to services
not explicitly configured (DNS), and these occasionally cause problems.

Are you referring to queries when doing PTR lookups for connecting
clients? I think that's one of the very reasons why "HostnameLookups
Off" was chosen for extra/httpd-default.conf.


Not HostnameLookups; resolving ServerName at startup (configured or 
defaulted).



Is there a principle at stake which could be followed consistently across
disparate features in how the server behaves a) with compiled in defaults
and minimal config, or b) with default/recommended config?

The default configuration should not trigger unsolicited outgoing
queries to untrusted systems, for both a) and b), that's how I would
put it.


Admin configures a certificate that has a domain name of attacker in the 
responder URI?  DNS entry for domain name in responder URI is taken over 
to point to attacker?



  Additionally, features enabled by default need to have sufficient
cove

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Jeff Trawick]

On 08/29/2015 08:10 PM, William A Rowe Jr wrote:


On Aug 29, 2015 1:49 PM, "Jeff Trawick" <traw...@gmail.com 
<mailto:traw...@gmail.com>> wrote:

>
> On 08/28/2015 04:17 PM, Tim Bannister wrote:
>>
>> Jeff Trawick <traw...@gmail.com <mailto:traw...@gmail.com>> wrote:
>>>
>>>
>>> As of now there's still a veto on my suggestion of enabling 
stapling by

>>> default in the httpd trunk config.
>>
>> Would that default need to be backported to 2.4.x?
>
>
> "need"?  No; 2.4.x is a separate consideration.
>
>
>> If it can be on by default for trunk/2.5.x, and off by default in 
earlier releases, this should surprise very few users.

>>
>> People upgrading from an older release could get a mild surprise, 
but at the same time if you upgrade from 2.4.x to 2.5.x then surprises 
aren't all that surprising.

>>
>> Overall I think the big question mark is around backport to 2.4.x 
rather than the change to httpd trunk.


I thought this question was largely resolved, that we wouldn't want 
subversion updates to break a users config unexpectedly.  POLS.


You know this, but just for completeness: 
Subversion-update-breaks-users-config is when compiled-in default 
behavior changes, which could affect configurations with no stapling 
directive, which wasn't proposed even for trunk.

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Jeff Trawick]

On Mon, Jul 13, 2015 at 3:08 AM, Ruediger Pluem rpl...@apache.org wrote:



 On 07/11/2015 08:55 PM, William A Rowe Jr wrote:

  If you are suggesting we shouldn't change the compiled-in default, I can
  agree, POLS (Principal Of Least Surprise).  If you are suggesting the
 default
  config shouldn't reflect the ability to efficiently handle OCSP by
 stapling, here
  I think we would disagree.

 This something I can agree with: Leave the default compiled in to off and
 in the configuration distributed by us have it
 set to on.

 Regards

 Rüdiger


As of now there's still a veto on my suggestion of enabling stapling by
default in the httpd trunk config.  Of Kaspar's justifications, I think
this is the text that remains of his clarifying post on July 11, ignoring
the license reference:

a) by default, an HTTP server is supposed to process *incoming* requests,
not make accidental outgoing connections in addition (at least not unless
it's explicitly instructed to do so);

(I sincerely hope I haven't misconstrued the situation or missed anything
Kaspar intended.)

Those of us in favor of enabling stapling by default for those using the
default configs wouldn't have any trouble finding opposite justifications.
For one, it is appropriate for the default config is there to enable
practices which are reasonable in most situations, and OCSP Stapling is
widely accepted as an appropriate feature for HTTP servers to enable.
Also, strictly speaking, the default config does not have SSL enabled
anyway, and after manually enabling it OCSP responses won't be fetched
unless a certificate is configured which references an OCSP responder.

While I find the not make accidental outgoing connections argument
compelling (though perhaps with a different word than accidental) the
server already takes actions that cause outgoing connections to services
not explicitly configured (DNS), and these occasionally cause problems.
Looking up the values of the User and Group directives can possibly invoke
one of multiple different network services depending on the system
configuration.  But I admit that's just fishing for a counter argument.

Any suggestions for breaking the apparent impasse?

Is there a principle at stake which could be followed consistently across
disparate features in how the server behaves a) with compiled in defaults
and minimal config, or b) with default/recommended config?

If enabling stapling were more closely tied in the configuration language
to configuring a certificate, which with SSLUseStapling On is the user
action that makes mod_ssl talk to a responder, would that help the end
user?  (Controlling stapling parameters on a per-certificate basis is
valuable anyway since you can have multiple certificates per vhost,
possibly with different responders.)

Thanks,

Jeff
-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: help: need mod_cgi.so win32 fixed

[Jeff Trawick]

On Sat, Aug 8, 2015 at 9:58 PM, Francesco Pasqualini fra...@gmail.com
wrote:

 Hi Eric,
 I confirm that the patch changes mod_cgi

 infact mod_cgi.c calls the function ap_create_environment in
 util_script.c:

 env = ap_create_environment(r-pool, r-subprocess_env);

 so applying the patch to util_script.c, recompiling mod_cgi.c and
 installing mod_cgi.so under the $root/modules dir will do the trick


No, util_script code is not included in individual modules; it is compiled
into the main httpd core, which on Windows is largely in libhttpd.dll.

There are a number of ways that httpd can be built on Windows (largely
based on the Microsoft compiler version and 32-bit vs. 64-bit but also
based on SDK level and support libraries).  The provider of your httpd
build would need to compile a new version for you in order to avoid
compatibility problems.





 thanks

 Francesco

 On Sat, Aug 8, 2015 at 8:33 PM, Eric Covener cove...@gmail.com wrote:

 On Sat, Aug 8, 2015 at 2:24 PM, Francesco Pasqualini fra...@gmail.com
 wrote:
  Hi to all,
 
  Can someone help me ?
 
  I have a httpd in production on windows affected by this problem:
 
  https://bz.apache.org/bugzilla/show_bug.cgi?id=46751#c4
 
  Can someone compile for me a fixed (john proposal) version of
 mod_cgi.so ?

 That patch doesn't change mod_cgi, you need a new httpd.exe or
 libhttpd.lib (not sure what goes where on Windows). Might have more
 luck on ApacheLounge with a test build of the entire server.





-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] [24 hr] Release 2.2.31 as GA?

[Jeff Trawick]

On 07/15/2015 12:44 PM, William A Rowe Jr wrote:
The pre-release candidate tarballs of Apache httpd 2.2.31, can be 
found in;


http://httpd.apache.org/dev/dist/

  +/-1

[X]  Release 2.2.31 GA (apr 1.5.2, apr-util 1.5.4)

The diffs look good to me.

I ran the test suite on FreeBSD 10 and obtained the same results as with 
2.2.29 and 2.2.30.


Thanks!

Re: [VOTE] Release 2.2.30 as GA?

[Jeff Trawick]

On Tue, Jul 14, 2015 at 9:06 AM, William A Rowe Jr wr...@rowe-clan.net
wrote:

 On Jul 11, 2015 10:29 AM, William A Rowe Jr wr...@rowe-clan.net wrote:

 
  The pre-release candidate tarballs of Apache httpd 2.2.30, can be found
 in;
 
  http://httpd.apache.org/dev/dist/

   [+1]  Release 2.2.30 GA (apr 1.5.2, apr-util 1.5.4)


 The PROXY_DECLARE bug doesn't seem to be a showstopper, the announce can
 make note of that fix.

 With that issue addressed, this is my +1 for release.


IOW, the vote passes with 4 votes in favor and 1 opposed.

3 of the +1s were cast before the problem was noted.




 Pushing to the mirrors ASAP.
 Bill





-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE WITHDRAWN] Release 2.2.30 as GA?

[Jeff Trawick]

On Tue, Jul 14, 2015 at 10:54 AM, William A Rowe Jr wr...@rowe-clan.net
wrote:

 On Tue, Jul 14, 2015 at 8:06 AM, William A Rowe Jr wr...@rowe-clan.net
 wrote:

 On Jul 11, 2015 10:29 AM, William A Rowe Jr wr...@rowe-clan.net
 wrote:

 
  The pre-release candidate tarballs of Apache httpd 2.2.30, can be found
 in;
 
  http://httpd.apache.org/dev/dist/

   [+1]  Release 2.2.30 GA (apr 1.5.2, apr-util 1.5.4)


 The PROXY_DECLARE bug doesn't seem to be a showstopper, the announce can
 make note of that fix.


 I misread Jeff's vote this morning (my appologies), and \retract my +1
 based on his concerns. I'm withdrawing this release from consideration (and
 it had not yet traveled to mirrors)

 I will prepare a single patch 2.2.31 based on this fix alone and resubmit
 to the group later today for an expedited 24 hour release vote, given that
 the delta is easily re-validated by existing reviewers..

 Bill


Thanks/Sorry :(

Re: building httpd 2.2 on windows automation question.

[Jeff Trawick]

On Tue, Jul 14, 2015 at 11:41 AM, Andy Wang aw...@ptc.com wrote:



 On 07/14/2015 10:36 AM, Mario Brandt wrote:

 Hi Andy,

 at least for the 2.4 there is a script on github [1]

 Maybe you can adopt that for 2.2. I wonder why you still want 2.2.
 Unless you use some exotic modules that do no build with 2.4,  2.4 is
 the better option.


 [1] https://github.com/winlibs/apache


 2.4 doesn't need to use the dsw/sln projects as it can use cmake, so yeah,
 I already have a script for 2.4.  We are also using 2.4, but have legacy
 products using 2.2 that need to be kept up to date and an update to 2.4
 would be too disruptive.. enterprise .. yadayadayada :)


cmake support for 2.2 should be a straightforward adjustment to 2.4 cmake
;)  (not anywhere visible on my priority list)


 Thanks,
 Andy




-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release Apache httpd 2.4.16 as GA

[Jeff Trawick]

On 07/10/2015 04:33 PM, Jim Jagielski wrote:

The pre-release test tarballs for Apache httpd 2.4.16 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.16 GA.

[ ] +1: Good to go
[ ] +0: meh
[ ] -1: Danger Will Robinson. And why.

Vote will last the normal 72 hrs.


wow, time waits for no man|woman :(  I'll try to sneak in some testing 
during the day...

Re: [VOTE] Release Apache httpd 2.4.16 as GA

[Jeff Trawick]

On Fri, Jul 10, 2015 at 4:33 PM, Jim Jagielski j...@jagunet.com wrote:

 The pre-release test tarballs for Apache httpd 2.4.16 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.16 GA.


[X] +1: Good to go

Test suite passed with prefork and event on:

CentOS 7 64-bit
FreeBSD 10.1, 32-bit, kernel accept filter not loaded
Fedora 22, 64-bit
Ubuntu 12, 32-bit*
Ubuntu 15, 32-bit*

*silly failure of t/filter/case.t due to an expected Perl doc file not
being installed

Of course it is not === 2.4.16, but today's 2.4.17-dev with mod_proxy_scgi
and a few Django apps works fine for me in a real deployment on Ubuntu 12.

Thanks for RM-ing, Jim!  Thanks everyone for your help testing, especially
non-committers!

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release 2.2.30 as GA?

[Jeff Trawick]

On Sat, Jul 11, 2015 at 10:29 AM, William A Rowe Jr wr...@rowe-clan.net
wrote:

 The pre-release candidate tarballs of Apache httpd 2.2.30, can be found
 in;

 http://httpd.apache.org/dev/dist/

   +/-1
   [  ]  Release 2.2.30 GA (apr 1.5.2, apr-util 1.5.4)


Thanks for RM-ing!

[-1] Don't release due to Windows build error for mod_proxy discussed in
this thread

I see no regressions when comparing with 2.2.29 on FreeBSD and Linux:

FreeBSD 10, 32-bit, no kernel accept filter loaded

2.2.30 with prefork

Test Summary Report
---
t/modules/cgi.t   (Wstat: 0 Tests: 58 Failed: 3)
  Failed tests:  55-57
t/security/CVE-2008-2364.t(Wstat: 0 Tests: 3 Failed: 2)
  Failed tests:  2-3
t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 1)
  Failed test:  2
t/ssl/require.t   (Wstat: 0 Tests: 10 Failed: 1)
  Failed test:  9
Files=110, Tests=4001, 134 wallclock secs ( 2.23 usr  0.54 sys + 50.54 cusr
12.99 csys = 66.30 CPU)
Result: FAIL

2.2.29 with prefork

Test Summary Report
---
t/apache/chunkinput.t (Wstat: 0 Tests: 37 Failed: 6)
  Failed tests:  23, 25, 31, 33, 35, 37
t/modules/cgi.t   (Wstat: 0 Tests: 58 Failed: 3)
  Failed tests:  55-57
t/security/CVE-2008-2364.t(Wstat: 0 Tests: 3 Failed: 2)
  Failed tests:  2-3
t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 1)
  Failed test:  2
t/ssl/require.t   (Wstat: 0 Tests: 10 Failed: 1)
  Failed test:  9
Files=110, Tests=4001, 123 wallclock secs ( 1.87 usr  0.51 sys + 43.73 cusr
11.53 csys = 57.64 CPU)
Result: FAIL

Ubuntu 12, 32-bit

2.2.30 with prefork

Test Summary Report
---
t/filter/case.t   (Wstat: 0 Tests: 4 Failed: 1)
  Failed test:  2
t/modules/cgi.t   (Wstat: 0 Tests: 58 Failed: 3)
  Failed tests:  55-57
t/security/CVE-2008-2364.t(Wstat: 0 Tests: 3 Failed: 2)
  Failed tests:  2-3
t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 1)
  Failed test:  2
t/ssl/require.t   (Wstat: 0 Tests: 10 Failed: 1)
  Failed test:  9
Files=110, Tests=3631, 128 wallclock secs ( 1.89 usr  0.23 sys + 41.57 cusr
 9.45 csys = 53.14 CPU)
Result: FAIL

2.2.29 with prefork

Test Summary Report
---
t/apache/chunkinput.t (Wstat: 0 Tests: 37 Failed: 6)
  Failed tests:  23, 25, 31, 33, 35, 37
t/filter/case.t   (Wstat: 0 Tests: 4 Failed: 1)
  Failed test:  2
t/modules/cgi.t   (Wstat: 0 Tests: 58 Failed: 3)
  Failed tests:  55-57
t/security/CVE-2008-2364.t(Wstat: 0 Tests: 3 Failed: 2)
  Failed tests:  2-3
t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 1)
  Failed test:  2
t/ssl/require.t   (Wstat: 0 Tests: 10 Failed: 1)
  Failed test:  9
Files=110, Tests=3631, 123 wallclock secs ( 1.62 usr  0.27 sys + 40.51 cusr
 8.77 csys = 51.17 CPU)
Result: FAIL

(my t/filter/case.t failures on Ubuntu are noise)

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Jeff Trawick]

On Sat, Jul 11, 2015 at 2:55 PM, William A Rowe Jr wr...@rowe-clan.net
wrote:

 We can have a dialog about the best behavior of our default config.
 However...

 On Sat, Jul 11, 2015 at 9:56 AM, Kaspar Brand httpd-dev.2...@velox.ch
 wrote:

 On 01.07.2015 14:27, Ben Laurie wrote:
  On 1 November 2014 at 09:05, Kaspar Brand httpd-dev.2...@velox.ch
 wrote:
  The fundamental objection I have to enabling stapling by default in our
  GA releases is that it would enable a phoning home feature (to the
  CA's OCSP responders) as a side effect of configuring a certificate.
  This is a setting I consider unacceptable for software published by the
  Apache HTTP Server project - the default must be opt-in, not opt-out.
 
  I've just become aware of this objection and would like to understand
  the thinking behind it. Firstly, it seems strange to call this
  phoning home, a term that _usually_ means connecting to the vendor
  of the s/w.
 
  But more importantly, what harm is there in a server connecting to the
  OCSP responders for the certificates it is serving? Why is this
  unacceptable?

 It's unacceptable for at least two reasons: a) by default, an HTTP
 server is supposed to process *incoming* requests, not make accidental
 outgoing connections in addition (at least not unless it's explicitly
 instructed to do so); b) there's no statement in our license with an
 explicit caveat on such a side effect (when relying on our default
 settings, configuring a site with an SSL server certificate may result
 in unsolicited outgoing HTTP requests - and no, I do not want to see
 our license amended by things like that).


 Our License says nothing about accepting requests, either.  Licenses
 don't express these mechanics.  They define the terms for users to
 reproduce, prepare Derivative Works of, publicly display, publicly
 perform,
 sublicense, and distribute the work and its derivatives, and the
 corresponding
 patent rights as well.

 A number of ASF works are servers.  A number are clients.  A number are
 both clients and servers.  OCSP is hardly an accidental request, any more
 than
 the proxy module requests.  And in forwarding requests to https proxy
 servers,
 (another side effect) verifying the OCSP identity of the connected server
 is
 hardly an unexpected side effect, it's a characteristic of the protocol
 (that
 backend *server* advertised OCSP validation - stapled or indirect, and that
 the *user* configured the certificate for OCSP validation).  Third party
 OCSP
 validation is so problematic that OCSP stapling is a blindly obvious
 enhancement
 that will far offset the routing configuration issues it also inspires

 So your premise above is, well, outright silly.


 I maintain my objection to uncommenting #SSLUseStapling On in our
 default config in httpd-ssl.conf.in - and for the record, also to
 changing code, be that in ssl_engine_config.c:modssl_ctx_init() or
 elsewhere. Those keen on enabling it by default on behalf of the users
 (because we know what is good for you) are free to lobby with the OS
 vendors to have their package defaults changed.


 You are welcome to object, and I think Ben's reply here to your thoughts
 and observations, particularly your early one, since he is advocating for
 this
 change and this would move the dialog along to a conclusion.

 Contrawise, httpd project can do the 'right thing' from our perspective,
 and
 the downstream distributors can correspondingly disable it.

 Moreso, any enterprise so affected already is configuring httpd to their
 own
 organization's standards and policies.

 If you are suggesting we shouldn't change the compiled-in default, I can
 agree, POLS (Principal Of Least Surprise).  If you are suggesting the
 default
 config shouldn't reflect the ability to efficiently handle OCSP by
 stapling, here
 I think we would disagree.


Not to anyone in particular:

Contacting the OCSP responder may indeed be a surprise, and it might not
even work due to to firewall rules being effectively surprised.  (DNS was
too once upon a time.)  It does require education on the part of some
administrators.  But:

No changes discussed actually change the behavior for any non-hypothetical
configuration, since SSL is not configured by default and no existing
configurations will magically start contacting the responder.  (The more
nuanced wording of OCSP stapling by default is IFF you're using the
latest httpd default configuration files, an OCSP responder pointed to in a
certificate you configure will be utilized, unless you say otherwise.).

The config change does move the key decision point regarding this new
concept to the basic enablement of SSL.  In retrospect, it might have been
wise to enable/disable stapling on the SSLCertificateFile directive, both
for the more granular control as well as making the admin see the setting
when performing that required bit of configuration.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Next release of mod_fcgid

[Jeff Trawick]

On Mon, Jun 22, 2015 at 11:42 AM, Mario Brandt jbl...@gmail.com wrote:

 r1604123: Lower log graceful kill fail, sending SIGKILL level to
 DEBUG on Windows. PR 54597.
 and
 r16041237: Follow up to r1604123: make it compile.

 I've now listed the fix in CHANGES-FCGID.  IMO it isn't worth rolling a
release for this.  I'm happy to TR and help test a mod_fcgid release that
has more fixes.  IIRC, there's some low-hanging fruit in Bugzilla that
interested developers can help test and promote.

(Not to say that this fix isn't important to some people, but they can
change WARNING to DEBUG  in the right place with zero risk.)



 Cheers
 Mario

 On 22 June 2015 at 16:59, Jeff Trawick traw...@gmail.com wrote:
  On Mon, Jun 22, 2015 at 10:14 AM, Mario Brandt jbl...@gmail.com wrote:
 
  Hi,
 
  the last release of mod_fcgid was been a long while.
 
  There was an important bugfix on windows side in June last year.
 
  Is there anyone willing to tag and release a new version?
 
 
  There's nothing in CHANGES.  What was it?
 
  --
  Born in Roswell... married an alien...
  http://emptyhammock.com/
 




-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Next release of mod_fcgid

[Jeff Trawick]

On Mon, Jun 22, 2015 at 10:14 AM, Mario Brandt jbl...@gmail.com wrote:

 Hi,

 the last release of mod_fcgid was been a long while.

 There was an important bugfix on windows side in June last year.

 Is there anyone willing to tag and release a new version?


There's nothing in CHANGES.  What was it?

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release Apache httpd 2.4.15 as GA

[Jeff Trawick]

On Mon, Jun 22, 2015 at 8:02 AM, Jim Jagielski j...@jagunet.com wrote:

 Seems that 3rd time was NOT the charm.

 Due to the regression I am canceling this VOTE.

 Let's patch 2.4.16-dev ASAP to handle this and I will TR 2.4.16
 forthwith.


Thanks, Jim!  We'll get through this eventually :)

(And thanks Steffen and Reindl too!)

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release Apache httpd 2.4.15 as GA

[Jeff Trawick]

On Fri, Jun 19, 2015 at 12:50 PM, Jim Jagielski j...@jagunet.com wrote:

 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.


[X] +1: Good to go

Test suite passed with prefork and event on:

CentOS 7 64-bit
FreeBSD 10.1, 32-bit, kernel accept filter not loaded
Fedora 22, 64-bit
Ubuntu 12, 32-bit*
Ubuntu 15, 32-bit*

*silly failure of t/filter/case.t due to an expected Perl doc file not
being installed

Built with cmake 3.1.3 and VS 2012 x64 on Windows, and served pages

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: svn commit: r1686446 - in /httpd/test/framework/trunk/t/ssl: pr12355.t pr43738.t

[Jeff Trawick]

On Fri, Jun 19, 2015 at 12:39 PM, rj...@apache.org wrote:

 Author: rjung
 Date: Fri Jun 19 16:39:15 2015
 New Revision: 1686446

 URL: http://svn.apache.org/r1686446
 Log:
 These tests need to use MD5 ciphers, which are
 by default disabled in modern Perl HTTPS support.
 Allow all ciphers here, so it should work as
 long as the underlying OpenSSL has it in ALL.

 Adding this option to the LWP::UserAgent should
 be transparent for older Perl or module versions
 that don't know about it.


Awesome, thanks!



 Modified:
 httpd/test/framework/trunk/t/ssl/pr12355.t
 httpd/test/framework/trunk/t/ssl/pr43738.t

 Modified: httpd/test/framework/trunk/t/ssl/pr12355.t
 URL:
 http://svn.apache.org/viewvc/httpd/test/framework/trunk/t/ssl/pr12355.t?rev=1686446r1=1686445r2=1686446view=diff

 ==
 --- httpd/test/framework/trunk/t/ssl/pr12355.t (original)
 +++ httpd/test/framework/trunk/t/ssl/pr12355.t Fri Jun 19 16:39:15 2015
 @@ -7,6 +7,7 @@ use Apache::TestUtil;

  plan tests = 10, need 'ssl', need_min_apache_version('2.0');

 +Apache::TestRequest::user_agent( ssl_opts = { SSL_cipher_list = 'ALL'});
  Apache::TestRequest::user_agent_keepalive(1);
  Apache::TestRequest::scheme('https');


 Modified: httpd/test/framework/trunk/t/ssl/pr43738.t
 URL:
 http://svn.apache.org/viewvc/httpd/test/framework/trunk/t/ssl/pr43738.t?rev=1686446r1=1686445r2=1686446view=diff

 ==
 --- httpd/test/framework/trunk/t/ssl/pr43738.t (original)
 +++ httpd/test/framework/trunk/t/ssl/pr43738.t Fri Jun 19 16:39:15 2015
 @@ -9,6 +9,7 @@ plan tests = 4,
  need 'ssl', need_module('actions'),
  need_min_apache_version('2.2.7');

 +Apache::TestRequest::user_agent( ssl_opts = { SSL_cipher_list = 'ALL'});
  Apache::TestRequest::user_agent_keepalive(1);
  Apache::TestRequest::scheme('https');






-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: option to block async write completion?

[Jeff Trawick]

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}_connection() allow you to remove that 
requirement?




There's already a path for forcing a blocking write of a particular
bucket, so it is a one-liner to add a new condition.  But I am having
trouble deciding how to best flip this on -- add a new request_rec
field? Use a request note? Some kind of other way for a module to
influence the core output filter directly?

This is the neighborhood in core_filters.c:

511 if (APR_BUCKET_IS_FLUSH(bucket)
512 || non_file_bytes_in_brigade = THRESHOLD_MAX_BUFFER
513 || morphing_bucket_in_brigade
514 || eor_buckets_in_brigade  MAX_REQUESTS_IN_PIPELINE) {
515 /* this segment of the brigade MUST be sent before returning. */
516
517 if (loglevel = APLOG_TRACE6) {
518 char *reason = APR_BUCKET_IS_FLUSH(bucket) ?
519FLUSH bucket :
520(non_file_bytes_in_brigade =
THRESHOLD_MAX_BUFFER) ?

Thanks for any ideas.   I would default to adding a request_rec field,
but we have been bitten by just extending request_rec and that is not
really addressed yet so I am hesitant.  I don't know how expensive a
note lookup is, but it seems bad to do anything un-necesary per-bucet.

Re: option to block async write completion?

[Jeff Trawick]

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 thread.


Can ap_hook_{suspend_resume}_connection() allow you to remove that 
requirement?

{suspend|resume}

Re: NOTE: Intent to TR 2.4.15 Tomorrow (Friday, June 19)

[Jeff Trawick]

On Thu, Jun 18, 2015 at 1:08 PM, Jim Jagielski j...@jagunet.com wrote:

 Subj sez it all.


+!

Re: NOTE: Intent to TR 2.4.15 Tomorrow (Friday, June 19)

[Jeff Trawick]

On Thu, Jun 18, 2015 at 3:03 PM, olli hauer oha...@gmx.de wrote:

 On 2015-06-18 19:08, Jim Jagielski wrote:
  Subj sez it all.
 

 I don't know if it is worth to report this, but the on 2.4.12. I don't see
 the following warnings


Are you using clang for both compiles?

(I think I saw those for 2.4.12,13,14 on FreeBSD 10.1 + Clang.)




 Test build 2.4.15 (Last Changed Rev: 1686275)

 --- core.lo ---
 core.c:5003:1: warning: unused variable 'aplog_module_index'
 [-Wunused-const-variable]
 AP_DECLARE_MODULE(core) = {
 ^
 /usr/ports/www/apache24/work/httpd-2.4.14/include/http_config.h:437:5:
 note: expanded from macro 'AP_DECLARE_MODULE'
 APLOG_USE_MODULE(foo); \
 ^
 /usr/ports/www/apache24/work/httpd-2.4.14/include/http_config.h:427:24:
 note: expanded from macro 'APLOG_USE_MODULE'
 static int * const aplog_module_index = (foo##_module.module_index)
^
 --- http_core.lo ---
 http_core.c:320:1: warning: unused variable 'aplog_module_index'
 [-Wunused-const-variable]
 AP_DECLARE_MODULE(http) = {
 ^
 /usr/ports/www/apache24/work/httpd-2.4.14/include/http_config.h:437:5:
 note: expanded from macro 'AP_DECLARE_MODULE'
 APLOG_USE_MODULE(foo); \
 ^
 /usr/ports/www/apache24/work/httpd-2.4.14/include/http_config.h:427:24:
 note: expanded from macro 'APLOG_USE_MODULE'
 static int * const aplog_module_index = (foo##_module.module_index)
^
 --- mod_buffer.slo ---
 ...





-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: SSLCertificateChainFile deprecation, still

[Jeff Trawick]

On Mon, Jun 15, 2015 at 10:54 AM, William A Rowe Jr wr...@rowe-clan.net
wrote:

 On Mon, Jun 15, 2015 at 8:12 AM, Eric Covener cove...@gmail.com wrote:

 Anyone else inclined to just remove the message? It's a deprecation that
 didn't happen on a release boundary. AFAICT there's no reason to change how
 you run your server unless you use two different cert chains and then you'd
 find the info in the manual.


 +1, this is highly irregular.  Our general statement is that config
 changes are not strictly necessary on subversion updates of httpd.
  (Securing your SSLCipherList notwithstanding.)

 Bill


+1, but IMO the whole idea should be revisited.

Storing intermediate certificates separately is a problem when you have
multiple certificates with different algorithms.  (Which server cert(s)
do/does the intermediate cert file go with?)

For cases where there's no ambiguity, we have a trade-off between

1) being able to get rid of the directive since the intermediate certs
don't necessarily need to be stored separately
2) a future migration headache, if not nightmare, for sites with many
vhosts where different users manage the certs

We need to favor #2.

For cases where there is an ambiguity, we should deprecate being able to
configure that, and visibly warn that there's a likely problem ASAP.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: SSLCertificateChainFile deprecation, still

[Jeff Trawick]

On Mon, Jun 15, 2015 at 11:10 AM, Jeff Trawick traw...@gmail.com wrote:

 On Mon, Jun 15, 2015 at 10:54 AM, William A Rowe Jr wr...@rowe-clan.net
 wrote:

 On Mon, Jun 15, 2015 at 8:12 AM, Eric Covener cove...@gmail.com wrote:

 Anyone else inclined to just remove the message? It's a deprecation that
 didn't happen on a release boundary. AFAICT there's no reason to change how
 you run your server unless you use two different cert chains and then you'd
 find the info in the manual.


 +1, this is highly irregular.  Our general statement is that config
 changes are not strictly necessary on subversion updates of httpd.
  (Securing your SSLCipherList notwithstanding.)

 Bill


 +1, but IMO the whole idea should be revisited.

 Storing intermediate certificates separately is a problem when you have
 multiple certificates with different algorithms.  (Which server cert(s)
 do/does the intermediate cert file go with?)

 For cases where there's no ambiguity, we have a trade-off between

 1) being able to get rid of the directive since the intermediate certs
 don't necessarily need to be stored separately
 2) a future migration headache, if not nightmare, for sites with many
 vhosts where different users manage the certs

 We need to favor #2.

 For cases where there is an ambiguity, we should deprecate being able to
 configure that, and visibly warn that there's a likely problem ASAP.


well, a likely problem can't be right, unless they just configured it and
it doesn't work correctly yet :)

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: TWS ; LWS permitted by RFC 7230 4.1.1? Apparently, no.

[Jeff Trawick]

On Mon, Jun 15, 2015 at 12:33 PM, William A Rowe Jr wr...@rowe-clan.net
wrote:

 Reviewing the spec, I cannot find where Sambar server is permitted to
 insert whitespace. I further reviewed the ABNF appendix, and it does not
 appear there, either.

 The spec seems unambiguous;

 chunk  = chunk-size [ chunk-ext ] CRLF
  chunk-data CRLF
 chunk-size = 1*HEXDIG
 last-chunk = 1*(0) [ chunk-ext ] CRLF


 There is no opportunity to use whitespace outside of chunk-ext.


 chunk-ext  = *( ; chunk-ext-name [ = chunk-ext-val ] )
 chunk-ext-name = token
 chunk-ext-val  = token / quoted-string


 The rules in section 3.2.3 have become extremely strict;


 3.2.3 https://tools.ietf.org/html/rfc7230#section-3.2.3.  Whitespace

This specification uses three rules to denote the use of linear
whitespace: OWS (optional whitespace), RWS (required whitespace), and
BWS (bad whitespace).

The OWS rule is used where zero or more linear whitespace octets
might appear.  For protocol elements where optional whitespace is
preferred to improve readability, a sender SHOULD generate the
optional whitespace as a single SP; otherwise, a sender SHOULD NOT
generate optional whitespace except as needed to white out invalid or
unwanted protocol elements during in-place message filtering.

The RWS rule is used when at least one linear whitespace octet is
required to separate field tokens.  A sender SHOULD generate RWS as a
single SP.

The BWS rule is used where the grammar allows optional whitespace
only for historical reasons.  A sender MUST NOT generate BWS in
messages.  A recipient MUST parse for such bad whitespace and remove
it before interpreting the protocol element.


 And section 3.6.1 of RFC2616 made no accommodation for whitespace, in the 
 first place.


 I think Sambar is wrong and we should not be supporting this.


 If we make provision to support this, we should be disallowing

 by default and add a directive to change the behavior.


 Thoughts?


1.3 (or 1.3-based servers) put whitespace there.
1.3.x, 2.0.x, 2.2.x, and 2.4.x (for all released x so far) accepts
whitespace there.
We can't change that by default in a stable branch.

This could be perhaps implemented in conjunction with sf's HttpStrict (?)
stuff in trunk (I have no clue what that does in practice, but it sounds
right).


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release Apache httpd 2.4.14 as GA

[Jeff Trawick]

On Sat, Jun 13, 2015 at 7:42 PM, Yann Ylavic ylavic@gmail.com wrote:

 On Sun, Jun 14, 2015 at 1:18 AM, Jeff Trawick traw...@gmail.com wrote:
  On Sat, Jun 13, 2015 at 6:06 PM, Yann Ylavic ylavic@gmail.com
 wrote:
 
  I did not look at pr12355.t and pr43738.t yet, however those passed in
  my tests, so it's probably something different.
 
 
  Just in case it wasn't clear, these aren't regressions.  I get them with
  prior releases on FreeBSD 10.1 also.

 Ah ok, those are possibly the same as I reported in [1] for the 2.4.13
 vote (in the Post Scriptum, about latest stable debian 8).

 
  I don't know if it is the Perl stack or OpenSSL or ??? that results in
 the
  consistent failure.  (This FreeBSD has a significantly newer Perl stack
 from
  system packages than CentOS 7.)  IIUC, Rainer has been reporting
  intermittent failures on various platforms for a while.

 It seems to be related to latest OpenSSL, maybe RC5 isn't handled anymore?


I just tried on Fedora 22...

For both the Perl interpreter/lib versions and OpenSSL versions, it seems
to be essentially

CentOS 7  FreeBSD 10.1  Fedora 22

and the one in the middle is the only one where I see the issue.

The CentOS and Fedora builds of OpenSSL are FIPS-enabled; I don't know how
that affects the enabled ciphers.



 [1]
 https://mail-archives.apache.org/mod_mbox/httpd-dev/201506.mbox/%3ccakq1svp7iojwolpjw6mwodxyxnhtvb32-rmm-zv_dqwjxr1...@mail.gmail.com%3E




-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: ********* Re: [VOTE] Release Apache httpd 2.4.14 as GA

[Jeff Trawick]

On Sat, Jun 13, 2015 at 8:25 PM, Yann Ylavic ylavic@gmail.com wrote:

 On Sun, Jun 14, 2015 at 2:18 AM, Jeff Trawick traw...@gmail.com wrote:
  On Sat, Jun 13, 2015 at 7:52 PM, Yann Ylavic ylavic@gmail.com
 wrote:
 
  On Sat, Jun 13, 2015 at 8:49 PM, Jeff Trawick traw...@gmail.com
 wrote:
  
   Those that know the original patch would presumably have a better way
 to
   code this.
  
   I recall that httpd 1.3 generally added whitespace after the chunk
 size
   as
   an optimization (pre-allocating space in BUFF for the largest possible
   chunk
   size I guess).  Is it appropriate to allow whitespace both before and
   after?
   The patch above only allows it after.
 
  Committed in r1685345, by allowing both space and tab, before and
  after the chunk-size.
  Thinking more about it, I see no reason to allow spaces before
  (especially if there is no compatibility issue), we probably should
  revert that part.
  Opinions?
 
 
  2.2 doesn't accept space or tab before the chunk size, so we don't need
 to
  accept that.

 OK, fixed in r1685347.


Works for me :)

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: ********* Re: [VOTE] Release Apache httpd 2.4.14 as GA

[Jeff Trawick]

On Sat, Jun 13, 2015 at 7:52 PM, Yann Ylavic ylavic@gmail.com wrote:

 On Sat, Jun 13, 2015 at 8:49 PM, Jeff Trawick traw...@gmail.com wrote:
 
  Those that know the original patch would presumably have a better way to
  code this.
 
  I recall that httpd 1.3 generally added whitespace after the chunk size
 as
  an optimization (pre-allocating space in BUFF for the largest possible
 chunk
  size I guess).  Is it appropriate to allow whitespace both before and
 after?
  The patch above only allows it after.

 Committed in r1685345, by allowing both space and tab, before and
 after the chunk-size.
 Thinking more about it, I see no reason to allow spaces before
 (especially if there is no compatibility issue), we probably should
 revert that part.
 Opinions?


2.2 doesn't accept space or tab before the chunk size, so we don't need to
accept that.

2.2 does accept spaces and tabs after the chunk size, so we do need to
accept that.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release Apache httpd 2.4.14 as GA

[Jeff Trawick]

On Sat, Jun 13, 2015 at 6:06 PM, Yann Ylavic ylavic@gmail.com wrote:

 On Sat, Jun 13, 2015 at 6:51 PM, Rainer Jung rainer.j...@kippdata.de
 wrote:
 
  any chance you can reproduce the problem with a slightly patched 2.4.14
 to
  get additional log output around the suspect code?
 
  The patch would be
 
  Index: modules/http/http_filters.c
  ===
  --- modules/http/http_filters.c (revision 1685283)
  +++ modules/http/http_filters.c (working copy)
  @@ -514,6 +514,9 @@
   rv = parse_chunk_size(ctx, buffer, len,
 
  f-r-server-limit_req_fieldsize);
   if (rv != APR_SUCCESS) {
  +ap_log_rerror(APLOG_MARK, APLOG_ERR, rv, f-r,
  APLOGNO(9)
  +  Error parsing chunk size, buffer
  %*.*s, limit %d,
  +  len, len, buffer,
  f-r-server-limit_req_fieldsize);
   if (rv != APR_ENOSPC) {
   http_error = HTTP_BAD_REQUEST;
   }

 Hmm, it seems that the backported patch in r1684515 is not the
 proposed/voted v5, where AH01590 would normally have been logged here.
 Bill, looks like v4 was applied instead... Attached is the diff on
 http_filter.c between the two patches.

 BTW, v5 does not address the regression encountered by Steffen either:
 space(s) between the chunk-size and the CRLF which are not allowed
 anymore.
 This is not really RFC compliant, but I guess we have to be lenient here...

 I did not look at pr12355.t and pr43738.t yet, however those passed in
 my tests, so it's probably something different.


Just in case it wasn't clear, these aren't regressions.  I get them with
prior releases on FreeBSD 10.1 also.

I don't know if it is the Perl stack or OpenSSL or ??? that results in the
consistent failure.  (This FreeBSD has a significantly newer Perl stack
from system packages than CentOS 7.)  IIUC, Rainer has been reporting
intermittent failures on various platforms for a while.



 Jeff, any idea where these failures can come from?
 What do -v and the logs say?


pr12355.t only:

# testing : renegotiation on POST works
# expected: 200
# received: 500
not ok 3
# testing : request body matches response
# expected: 'hello world'
# received: 'Status read failed:  at
/usr/local/lib/perl5/site_perl/Net/HTTP/Methods.pm line 289.
# '
not ok 4
...
# testing : renegotiation on POST works
# expected: 200
# received: 500
not ok 7
# testing : request body matches response
# expected: 'xx...
# received: 'Status read failed:  at
/usr/local/lib/perl5/site_perl/Net/HTTP/Methods.pm line 289.
# '
not ok 8

I think this is the underlying failure I'm seeing, possibly for both
testcases:

Sat Jun 13 23:08:55.005710 2015] [ssl:error] [pid 3745] [client
127.0.0.1:44064] AH02261: Re-negotiation handshake failed
[Sat Jun 13 23:08:55.005743 2015] [ssl:error] [pid 3745] SSL Library Error:
error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher -- Too
restrictive SSLCipherSuite or using DSA server certificate?



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release Apache httpd 2.4.14 as GA

[Jeff Trawick]

On Sat, Jun 13, 2015 at 8:31 AM, Steffen i...@apachelounge.com wrote:

 Tested with 2.4.13 tarball, then no error.


Wow...

Is anything written to the error log when you try proxy to the Sambar
server?  If my guess about the related code is correct, you'll need
LogLevel Info (or debug or trace) to see all the relevant messages.




 -Original Message- From: Steffen
 Sent: Saturday, June 13, 2015 1:33 PM Newsgroups: gmane.comp.apache.devel
 To: dev@httpd.apache.org
 Subject: Re: [VOTE] Release Apache httpd 2.4.14 as GA


 Regression: All works fine except a Proxy Pass  to Sambar server, was
 working ok with 2.4.12.

 ProxyPasses to other servers the Sambar works fine.

 ProxyPass /sysadmin http://127.0.0.1:81/sysadmin
 ProxyPassReverse /sysadmin http://127.0.0.1:81/sysadmin

 Calling with http://127.0.0.1:8080/sysadmin/ gives AH01110: error reading
 response :

 [Sat Jun 13 13:23:08.010826 2015] [authz_core:debug] [pid 5684:tid 1128]
 mod_authz_core.c(834): [client ::1:51072] AH01628: authorization result:
 granted (no directives)
 [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
 mod_proxy.c(1157): [client ::1:51072] AH01143: Running scheme http handler
 (attempt 0)
 [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
 proxy_util.c(2145): AH00942: HTTP: has acquired connection for (127.0.0.1)
 [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
 proxy_util.c(2199): [client ::1:51072] AH00944: connecting
 http://127.0.0.1:81/sysadmin/ to 127.0.0.1:81
 [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
 proxy_util.c(2408): [client ::1:51072] AH00947: connected /sysadmin/ to
 127.0.0.1:81
 [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
 proxy_util.c(2782): AH02824: HTTP: connection established with
 127.0.0.1:81
 (127.0.0.1)
 [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
 proxy_util.c(2936): AH00962: HTTP: connection complete to 127.0.0.1:81
 (127.0.0.1)
 [Sat Jun 13 13:23:08.010826 2015] [proxy_http:error] [pid 5684:tid 1128]
 (20014)Internal error (specific information not available): [client
 ::1:51072] AH01110: error reading response
 [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
 proxy_util.c(2160): AH00943: HTTP: has released connection for (127.0.0.1)
 [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
 proxy_util.c(2878): [remote 127.0.0.1:81] AH02642: proxy: connection
 shutdown



 -Original Message- From: Jim Jagielski
 Sent: Thursday, June 11, 2015 4:08 PM Newsgroups: gmane.comp.apache.devel
 To: httpd
 Subject: [VOTE] Release Apache httpd 2.4.14 as GA

 The pre-release test tarballs for Apache httpd 2.4.14 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.14 GA.

 [ ] +1: Good to go
 [ ] +0: meh
 [ ] -1: Danger Will Robinson. And why.

 Vote will last the normal 72 hrs.

 NOTE: The *-deps are only there for convenience.

 Thx!




-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release Apache httpd 2.4.14 as GA

[Jeff Trawick]

On Thu, Jun 11, 2015 at 10:08 AM, Jim Jagielski j...@jagunet.com wrote:

 The pre-release test tarballs for Apache httpd 2.4.14 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.14 GA.

 [ ] +1: Good to go
 [ ] +0: meh
 [ ] -1: Danger Will Robinson. And why.


CentOS 7, 64-bit: HTTP::DAV skipped; event and prefork tested, no failures

FreeBSD 10.1, 32-bit: lua skipped, accept filter not loaded, event and
prefork tested

Test Summary Report
---
t/ssl/pr12355.t   (Wstat: 0 Tests: 10 Failed: 4)
  Failed tests:  3-4, 7-8
t/ssl/pr43738.t   (Wstat: 0 Tests: 4 Failed: 2)
  Failed tests:  1-2

(same as with 2.4.13)

My vote: -1 for now :(

Steffen's apparent regression between 2.4.13 and 2.4.14 needs to be
investigated if he is able to assist further.  Other than that, I am
concerned about the console message issue with lots of SSL-enabled vhosts
but no per-vhost LogLevel (no deprecation messages before, lots now) but I
think that could be addressed in a recommended patch.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release Apache httpd 2.4.14 as GA

[Jeff Trawick]

On Sat, Jun 13, 2015 at 9:36 AM, Steffen i...@apachelounge.com wrote:

   Debug 2.4.14 was already in my first post.


sorry!



 The 2.4.13 (no error)  and 2.4.14 debug level error.log:

 Apache/2.4.13 (Win32)
 

 [Sat Jun 13 15:23:23.031198 2015] [authz_core:debug] [pid 9208:tid 1168]
 mod_authz_core.c(834): [client 127.0.0.1:54501] AH01628: authorization
 result: granted (no directives)
 [Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168]
 mod_proxy.c(1157): [client 127.0.0.1:54501] AH01143: Running scheme http
 handler (attempt 0)
 [Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168]
 proxy_util.c(2145): AH00942: HTTP: has acquired connection for (127.0.0.1)
 [Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168]
 proxy_util.c(2199): [client 127.0.0.1:54501] AH00944: connecting
 http://127.0.0.1:81/sysadmin/ to 127.0.0.1:81
 [Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168]
 proxy_util.c(2408): [client 127.0.0.1:54501] AH00947: connected
 /sysadmin/ to 127.0.0.1:81
 [Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168]
 proxy_util.c(2782): AH02824: HTTP: connection established with
 127.0.0.1:81 (127.0.0.1)
 [Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168]
 proxy_util.c(2936): AH00962: HTTP: connection complete to 127.0.0.1:81
 (127.0.0.1)
 [Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168]
 proxy_util.c(2160): AH00943: http: has released connection for (127.0.0.1)



 Apache/2.4.14 (Win32)
 =

 [Sat Jun 13 15:20:54.616551 2015] [authz_core:debug] [pid 4676:tid 1152]
 mod_authz_core.c(834): [client 127.0.0.1:54430] AH01628: authorization
 result: granted (no directives)
 [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
 mod_proxy.c(1157): [client 127.0.0.1:54430] AH01143: Running scheme http
 handler (attempt 0)
 [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
 proxy_util.c(2145): AH00942: HTTP: has acquired connection for (127.0.0.1)
 [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
 proxy_util.c(2199): [client 127.0.0.1:54430] AH00944: connecting
 http://127.0.0.1:81/sysadmin/ to 127.0.0.1:81
 [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
 proxy_util.c(2408): [client 127.0.0.1:54430] AH00947: connected
 /sysadmin/ to 127.0.0.1:81
 [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
 proxy_util.c(2782): AH02824: HTTP: connection established with
 127.0.0.1:81 (127.0.0.1)
 [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
 proxy_util.c(2936): AH00962: HTTP: connection complete to 127.0.0.1:81
 (127.0.0.1)
 [Sat Jun 13 15:20:54.616551 2015] [proxy_http:error] [pid 4676:tid 1152]
 (20014)Internal error (specific information not available): [client
 127.0.0.1:54430] AH01110: error reading response
 [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
 proxy_util.c(2160): AH00943: HTTP: has released connection for (127.0.0.1)



AH01110 reading backend server response...

Just looking for APR_EGENERAL in modified code that doesn't have a log
message, I guess it is chunked and we hit this APR_EGENERAL (Internal
error):

+else {
+/* Should not happen */
+return APR_EGENERAL;
+ }

Any better guesses out there?




  *From:* Jeff Trawick traw...@gmail.com
 *Sent:* Saturday, June 13, 2015 3:14 PM
 *Newsgroups:* gmane.comp.apache.devel
 *To:* Apache HTTP Server Development List dev@httpd.apache.org
 *Subject:* Re: [VOTE] Release Apache httpd 2.4.14 as GA

   On Sat, Jun 13, 2015 at 8:31 AM, Steffen i...@apachelounge.com wrote:

 Tested with 2.4.13 tarball, then no error.


 Wow...

 Is anything written to the error log when you try proxy to the Sambar
 server?  If my guess about the related code is correct, you'll need
 LogLevel Info (or debug or trace) to see all the relevant messages.




 -Original Message- From: Steffen
 Sent: Saturday, June 13, 2015 1:33 PM Newsgroups: gmane.comp.apache.devel
 To: dev@httpd.apache.org
 Subject: Re: [VOTE] Release Apache httpd 2.4.14 as GA


 Regression: All works fine except a Proxy Pass  to Sambar server, was
 working ok with 2.4.12.

 ProxyPasses to other servers the Sambar works fine.

 ProxyPass /sysadmin http://127.0.0.1:81/sysadmin
 ProxyPassReverse /sysadmin http://127.0.0.1:81/sysadmin

 Calling with http://127.0.0.1:8080/sysadmin/ gives AH01110: error reading
 response :

 [Sat Jun 13 13:23:08.010826 2015] [authz_core:debug] [pid 5684:tid 1128]
 mod_authz_core.c(834): [client ::1:51072] AH01628: authorization result:
 granted (no directives)
 [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
 mod_proxy.c(1157): [client ::1:51072] AH01143: Running scheme http handler
 (attempt 0)
 [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
 proxy_util.c(2145): AH00942: HTTP: has acquired connection for (127.0.0.1)
 [Sat Jun

Re: ********* Re: [VOTE] Release Apache httpd 2.4.14 as GA

[Jeff Trawick]

] [pid 9208:tid 1168]
 proxy_util.c(2936): AH00962: HTTP: connection complete to 127.0.0.1:81
 (127.0.0.1)
 [Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168]
 proxy_util.c(2160): AH00943: http: has released connection for
 (127.0.0.1)
 Apache/2.4.14 (Win32)
 =
 [Sat Jun 13 15:20:54.616551 2015] [authz_core:debug] [pid 4676:tid 1152]
 mod_authz_core.c(834): [client 127.0.0.1:54430] AH01628: authorization
 result: granted (no directives)
 [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
 mod_proxy.c(1157): [client 127.0.0.1:54430] AH01143: Running scheme http
 handler (attempt 0)
 [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
 proxy_util.c(2145): AH00942: HTTP: has acquired connection for
 (127.0.0.1)
 [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
 proxy_util.c(2199): [client 127.0.0.1:54430] AH00944: connecting
 http://127.0.0.1:81/sysadmin/ to 127.0.0.1:81
 [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
 proxy_util.c(2408): [client 127.0.0.1:54430] AH00947: connected
 /sysadmin/ to 127.0.0.1:81
 [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
 proxy_util.c(2782): AH02824: HTTP: connection established with
 127.0.0.1:81 (127.0.0.1)
 [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
 proxy_util.c(2936): AH00962: HTTP: connection complete to 127.0.0.1:81
 (127.0.0.1)
 [Sat Jun 13 15:20:54.616551 2015] [proxy_http:error] [pid 4676:tid 1152]
 (20014)Internal error (specific information not available): [client
 127.0.0.1:54430] AH01110: error reading response
 [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
 proxy_util.c(2160): AH00943: HTTP: has released connection for
 (127.0.0.1)
 *From:* Jeff Trawick mailto:traw...@gmail.com
 *Sent:* Saturday, June 13, 2015 3:14 PM
 *Newsgroups:* gmane.comp.apache.devel
 *To:* Apache HTTP Server Development List mailto:dev@httpd.apache.org
 *Subject:* Re: [VOTE] Release Apache httpd 2.4.14 as GA
 On Sat, Jun 13, 2015 at 8:31 AM, Steffen i...@apachelounge.com
 mailto:i...@apachelounge.com wrote:

  Tested with 2.4.13 tarball, then no error.

 Wow...
 Is anything written to the error log when you try proxy to the Sambar
 server?  If my guess about the related code is correct, you'll need
 LogLevel Info (or debug or trace) to see all the relevant messages.


  -Original Message- From: Steffen
  Sent: Saturday, June 13, 2015 1:33 PM Newsgroups:
  gmane.comp.apache.devel
  To: dev@httpd.apache.org mailto:dev@httpd.apache.org
  Subject: Re: [VOTE] Release Apache httpd 2.4.14 as GA


  Regression: All works fine except a Proxy Pass  to Sambar
 server, was
  working ok with 2.4.12.

  ProxyPasses to other servers the Sambar works fine.

  ProxyPass /sysadmin http://127.0.0.1:81/sysadmin
  ProxyPassReverse /sysadmin http://127.0.0.1:81/sysadmin

  Calling with http://127.0.0.1:8080/sysadmin/ gives AH01110:
 error
  reading
  response :

  [Sat Jun 13 13:23:08.010826 2015] [authz_core:debug] [pid
 5684:tid 1128]
  mod_authz_core.c(834): [client ::1:51072] AH01628:
 authorization result:
  granted (no directives)
  [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid
 1128]
  mod_proxy.c(1157): [client ::1:51072] AH01143: Running scheme
 http
  handler
  (attempt 0)
  [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid
 1128]
  proxy_util.c(2145): AH00942: HTTP: has acquired connection for
  (127.0.0.1)
  [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid
 1128]
  proxy_util.c(2199): [client ::1:51072] AH00944: connecting
  http://127.0.0.1:81/sysadmin/ to 127.0.0.1:81 http://127.0.0.1:81
  [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid
 1128]
  proxy_util.c(2408): [client ::1:51072] AH00947: connected
 /sysadmin/ to
  127.0.0.1:81 http://127.0.0.1:81
  [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid
 1128]
  proxy_util.c(2782): AH02824: HTTP: connection established with
  127.0.0.1:81 http://127.0.0.1:81
  (127.0.0.1)
  [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid
 1128]
  proxy_util.c(2936): AH00962: HTTP: connection complete to
  127.0.0.1:81 http://127.0.0.1:81
  (127.0.0.1)
  [Sat Jun 13 13:23:08.010826 2015] [proxy_http:error] [pid
 5684:tid 1128]
  (20014)Internal error (specific information not available):
 [client
  ::1:51072] AH01110: error reading response
  [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid
 1128]
  proxy_util.c(2160): AH00943: HTTP: has released connection for
  (127.0.0.1)
  [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid
 1128

Re: [VOTE] Release Apache httpd 2.4.14 as GA

[Jeff Trawick]

On Sat, Jun 13, 2015 at 9:24 AM, Jeff Trawick traw...@gmail.com wrote:

 On Thu, Jun 11, 2015 at 10:08 AM, Jim Jagielski j...@jagunet.com wrote:

 The pre-release test tarballs for Apache httpd 2.4.14 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.14 GA.

 [ ] +1: Good to go
 [ ] +0: meh
 [ ] -1: Danger Will Robinson. And why.


 CentOS 7, 64-bit: HTTP::DAV skipped; event and prefork tested, no failures

 FreeBSD 10.1, 32-bit: lua skipped, accept filter not loaded, event and
 prefork tested

 Test Summary Report
 ---
 t/ssl/pr12355.t   (Wstat: 0 Tests: 10 Failed: 4)
   Failed tests:  3-4, 7-8
 t/ssl/pr43738.t   (Wstat: 0 Tests: 4 Failed: 2)
   Failed tests:  1-2

 (same as with 2.4.13)

 My vote: -1 for now :(


That won't change :(  I don't think we can proxy to httpd 1.3[-based]
servers anymore and accept chunked responses.


 Steffen's apparent regression between 2.4.13 and 2.4.14 needs to be
 investigated if he is able to assist further.  Other than that, I am
 concerned about the console message issue with lots of SSL-enabled vhosts
 but no per-vhost LogLevel (no deprecation messages before, lots now) but I
 think that could be addressed in a recommended patch.




-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: svn commit: r1685052 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_config.c

[Jeff Trawick]

On Fri, Jun 12, 2015 at 5:07 AM, yla...@apache.org wrote:

 Author: ylavic
 Date: Fri Jun 12 09:07:34 2015
 New Revision: 1685052

 URL: http://svn.apache.org/r1685052
 Log:
 mod_ssl: Warn about deprecated SSLCertificateChainFile once at startup,
 on first usage only.

 Modified:
 httpd/httpd/trunk/CHANGES
 httpd/httpd/trunk/modules/ssl/ssl_engine_config.c

 Modified: httpd/httpd/trunk/CHANGES
 URL:
 http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1685052r1=1685051r2=1685052view=diff

 ==
 --- httpd/httpd/trunk/CHANGES [utf-8] (original)
 +++ httpd/httpd/trunk/CHANGES [utf-8] Fri Jun 12 09:07:34 2015
 @@ -1,6 +1,9 @@
   -*- coding:
 utf-8 -*-
  Changes with Apache 2.5.0

 +  *) mod_ssl: Warn about deprecated SSLCertificateChainFile once at
 startup,
 + on first usage only.  [Yann Ylavic]
 +
*) mod_substitute: Fix configuraton merge order.
   PR 57641 [Marc.Stern approach.be]


 Modified: httpd/httpd/trunk/modules/ssl/ssl_engine_config.c
 URL:
 http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_config.c?rev=1685052r1=1685051r2=1685052view=diff

 ==
 --- httpd/httpd/trunk/modules/ssl/ssl_engine_config.c (original)
 +++ httpd/httpd/trunk/modules/ssl/ssl_engine_config.c Fri Jun 12 09:07:34
 2015
 @@ -839,13 +839,22 @@ const char *ssl_cmd_SSLCertificateChainF
  const char *arg)
  {
  SSLSrvConfigRec *sc = mySrvConfig(cmd-server);
 +void *once = NULL;
  const char *err;

 -ap_log_error(APLOG_MARK, APLOG_WARNING|APLOG_STARTUP, 0, NULL,
 - APLOGNO(02559)
 - The SSLCertificateChainFile directive (%s:%d) is
 deprecated, 
 - SSLCertificateFile should be used instead,
 - cmd-directive-filename, cmd-directive-line_num);
 +apr_pool_userdata_get(once, ssl_cmd_SSLCertificateChainFile,
 +  ap_pglobal);
 +if (!once) {
 +ap_log_error(APLOG_MARK, APLOG_WARNING|APLOG_STARTUP, 0, NULL,
 + APLOGNO(02559)
 + The SSLCertificateChainFile directive (%s:%d) is 
 + deprecated, SSLCertificateFile should be used
 instead,
 + cmd-directive-filename, cmd-directive-line_num);
 +
 +apr_pool_userdata_set(ssl_cmd_SSLCertificateChainFile,
 +  apr_pstrdup(ap_pglobal, 1), NULL,
 +  ap_pglobal);
 +}

 IMHO the  ap_retained_data_get/create APIs make this nicer than this
older pattern.

retained = ap_retained_data_get(userdata_key);
if (!retained) {
retained = ap_retained_data_create(userdata_key, sizeof(*retained))



 if ((err = ssl_cmd_check_file(cmd, arg))) {
  return err;





-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release Apache httpd 2.4.14 as GA

[Jeff Trawick]

On Fri, Jun 12, 2015 at 1:35 PM, Jeff Trawick traw...@gmail.com wrote:

 On Fri, Jun 12, 2015 at 1:31 PM, Jeff Trawick traw...@gmail.com wrote:

 On Fri, Jun 12, 2015 at 1:25 PM, Rainer Jung rainer.j...@kippdata.de
 wrote:

 Am 12.06.2015 um 19:12 schrieb William A Rowe Jr:

 Revision 1678233 - (view) (download) (annotate) - [select for diffs]
 Modified Thu May 7 16:26:43 2015 UTC (5 weeks, 1 day ago) by jim
 File length: 57106 byte(s)
 Diff to previous 1674655 (colored)
 Merge r1676085 from trunk:

 consistently output SSLCertificateChainFile deprecation warnings
 Submitted by: kbrand
 Reviewed/backported by: jim

 sent the warnings to the console/main server error log, rather than a
 specific server error log file.  Because this is during config parsing,
 it that may have previously been a bit bucket.  So this could be
 perceived as a regression although the logic and log file activity was
 there for some time.


 Indeed there was a discussion thread for r1562500 in 2014 during which
 Falco Schwarz reported, that he did *not* get the log message a anywhere
 (neither console, not log files) when he had the directive only in
 VirtualHosts. After the 2.4.13 change it seems to be new, that you get the
 message massively on console, if you have the directive in frequent use
 inside VHosts. That might well be perceived as a regression.

 The 2.4.13 change replaced cmd-server in ap_log_error by NULL. The log
 level APLOG_WARNING|APLOG_STARTUP was not changed.

 Rainer


 I definitely have the old code and the SPAM...  I wonder if before you
 didn't see it if you didn't have vhost-specific logs configured, and now
 you see it regardless?


 so weird:

 With the old code, I have globally LogLevel debug and in a vhost
 LogLevel warn ; if I comment out that vhost's LogLevel I don't see the
 message even though I have ErrorLog in the vhost and *should* inherit the
 global LogLevel.


 --
 Born in Roswell... married an alien...
 http://emptyhammock.com/




 --
 Born in Roswell... married an alien...
 http://emptyhammock.com/


I'm a flip-flopper who didn't understand the subtlety of this before...  I
say regression, though I think it is acceptable to have a tiny
recommended patch for those affected.

As for why one or more messages hits the console for something to be dealt
with by the time you upgrade to an as-yet-non-existing future release
stream, I don't have any justification.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release Apache httpd 2.4.14 as GA

[Jeff Trawick]

On Fri, Jun 12, 2015 at 12:58 PM, Eric Covener cove...@gmail.com wrote:

 It doesn't make sense for us to hold up a release when that change has
 been in the last several releases however.  (That's a high barrier for
 making progress.)


 There seems to be a 2.4.8 component and an actual 2.4.13 component. Did
 the 2.4.13 fix make it more frequent.

 (fixing my top-post)


Hmmm, I have one situation with a 2.4.11-dev server that spits it out once
for each (similarly configured) vhost, so I may have been unlucky earlier
than some others.



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release Apache httpd 2.4.14 as GA

[Jeff Trawick]

On Fri, Jun 12, 2015 at 12:35 PM, Jacob Perkins jacob.perk...@cpanel.net
wrote:

 +1 to Noels comments.  We have a ton of servers running Apache 2.4 with
 our control panel.  Doing this in a point release will cause us to have to
 change our product instead of doing a regular Apache release.

 When you have a server with 10k+ SSL vhosts, this can cause massive,
 unexpected problems. I have a feeling that this will cause massive
 headaches with all those running Apache 2.4.


Thanks to Noel's comments, we have dropped this to one message at a quieter
log level for the next 2.4.x release, and we can assist with a tiny patch
to any recent 2.4.x.

It doesn't make sense for us to hold up a release when that change has been
in the last several releases however.  (That's a high barrier for making
progress.)

Make sense?


—
 Jacob Perkins
 Product Owner
 *cPanel Inc.*

 jacob.perk...@cpanel.net
 Office:  713-529-0800 x 4046
 Cell:  713-560-8655

 On Jun 11, 2015, at 8:37 PM, Noel Butler noel.but...@ausics.net wrote:

 On 12/06/2015 00:08, Jim Jagielski wrote:


 I'm calling a VOTE on releasing these as Apache httpd 2.4.14 GA.

 [ ] +1: Good to go
 [ ] +0: meh
 [ ] -1: Danger Will Robinson. And why.

 -1

 The SSLCertificateChainFile directive () is deprecated,
 SSLCertificateFile should be used instead

 The constant warnings on start, stop, and even reload for every single SSL
 host is unacceptable.

 This should never have been contemplated for a point release anyway.

 Clearly no consideration has been given to the headaches and collateral
 damage this will cause, some hosts have tens of thousands of SSL hosts,
 even a server reload will flood the hell out of them, most system/CP
 scripts look for a specific, or no output, after reload, this results in
 unexpected output and will trigger alarms, likely causing many systems to
 think  oh there was a problem adding this host, so I wont continue adding
 them into anything else and fail the entire new customer process again,
 creating serious problems for those required to maintain these things.


 It might be fine and dandy for a stand alone single SSL host server that
 is manually managed, but dont forget many hosts run up to 2+K hosts on a
 single server with many of them SSL, that is a lot of change when you have
 a server room half full of them, not to mention any inhouse scripting or
 control panels that will need to be modified to cater for such changes to
 create the new certs and deal with it all.


 I for one will not place this release on any production servers. My
 recommendation is that chainfile remain as it is - at the very least for
 the 2.4 series, and if it is not enough to stop or delay this release to
 revert, then I sincerely hope it is changed in trunk for the next.






-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release Apache httpd 2.4.14 as GA

[Jeff Trawick]

On Fri, Jun 12, 2015 at 1:25 PM, Rainer Jung rainer.j...@kippdata.de
wrote:

 Am 12.06.2015 um 19:12 schrieb William A Rowe Jr:

 Revision 1678233 - (view) (download) (annotate) - [select for diffs]
 Modified Thu May 7 16:26:43 2015 UTC (5 weeks, 1 day ago) by jim
 File length: 57106 byte(s)
 Diff to previous 1674655 (colored)
 Merge r1676085 from trunk:

 consistently output SSLCertificateChainFile deprecation warnings
 Submitted by: kbrand
 Reviewed/backported by: jim

 sent the warnings to the console/main server error log, rather than a
 specific server error log file.  Because this is during config parsing,
 it that may have previously been a bit bucket.  So this could be
 perceived as a regression although the logic and log file activity was
 there for some time.


 Indeed there was a discussion thread for r1562500 in 2014 during which
 Falco Schwarz reported, that he did *not* get the log message a anywhere
 (neither console, not log files) when he had the directive only in
 VirtualHosts. After the 2.4.13 change it seems to be new, that you get the
 message massively on console, if you have the directive in frequent use
 inside VHosts. That might well be perceived as a regression.

 The 2.4.13 change replaced cmd-server in ap_log_error by NULL. The log
 level APLOG_WARNING|APLOG_STARTUP was not changed.

 Rainer


I definitely have the old code and the SPAM...  I wonder if before you
didn't see it if you didn't have vhost-specific logs configured, and now
you see it regardless?

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release Apache httpd 2.4.14 as GA

[Jeff Trawick]

On Fri, Jun 12, 2015 at 1:31 PM, Jeff Trawick traw...@gmail.com wrote:

 On Fri, Jun 12, 2015 at 1:25 PM, Rainer Jung rainer.j...@kippdata.de
 wrote:

 Am 12.06.2015 um 19:12 schrieb William A Rowe Jr:

 Revision 1678233 - (view) (download) (annotate) - [select for diffs]
 Modified Thu May 7 16:26:43 2015 UTC (5 weeks, 1 day ago) by jim
 File length: 57106 byte(s)
 Diff to previous 1674655 (colored)
 Merge r1676085 from trunk:

 consistently output SSLCertificateChainFile deprecation warnings
 Submitted by: kbrand
 Reviewed/backported by: jim

 sent the warnings to the console/main server error log, rather than a
 specific server error log file.  Because this is during config parsing,
 it that may have previously been a bit bucket.  So this could be
 perceived as a regression although the logic and log file activity was
 there for some time.


 Indeed there was a discussion thread for r1562500 in 2014 during which
 Falco Schwarz reported, that he did *not* get the log message a anywhere
 (neither console, not log files) when he had the directive only in
 VirtualHosts. After the 2.4.13 change it seems to be new, that you get the
 message massively on console, if you have the directive in frequent use
 inside VHosts. That might well be perceived as a regression.

 The 2.4.13 change replaced cmd-server in ap_log_error by NULL. The log
 level APLOG_WARNING|APLOG_STARTUP was not changed.

 Rainer


 I definitely have the old code and the SPAM...  I wonder if before you
 didn't see it if you didn't have vhost-specific logs configured, and now
 you see it regardless?


so weird:

With the old code, I have globally LogLevel debug and in a vhost
LogLevel warn ; if I comment out that vhost's LogLevel I don't see the
message even though I have ErrorLog in the vhost and *should* inherit the
global LogLevel.


 --
 Born in Roswell... married an alien...
 http://emptyhammock.com/




-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release Apache httpd 2.4.13 as GA

[Jeff Trawick]

On Sun, Jun 7, 2015 at 1:20 PM, Rainer Jung rainer.j...@kippdata.de wrote:

  Am 04.06.2015 um 18:33 schrieb Jim Jagielski:

 The pre-release test tarballs for Apache httpd 2.4.13 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.13 GA.

 [X] +1: Good to go
 [ ] +0: meh
 [ ] -1: Danger Will Robinson. And why.

 Vote will last the normal 72 hrs.


 +1 to release, thanks for RMing.

 In short: No regressions found.

 Detailed report:

 - Sigs and hashes OK
 - contents of tarballs identical
 - contents of tag and tarballs identical
   except for expected deltas
   (we could cleanup some m4 files in apr-util/xml/expat/conftools
at the end of buildconf, no regression)

 Built on

 - Solaris 10 Sparc as 32 Bit Binaries
 - SLES 10+11 (64 Bits)
 - RHEL 6 (64 Bits)
 - FreeBSD 9.1

 On FreeBSD 2.4.12 runs on one machine for the ASF. No obvious problems
 showed up.

 For all platforms except FreeBSD built

 - with default (shared) and static modules
 - with module sets none, few, most, all, reallyall and default
   (always mod_privileges disabled)
 - using --enable-load-all-modules
 - against included APR/APU from deps tarball,
   plus external APR/APU 1.5.2/1.5.4

 - using external libraries
   - expat 2.1.0
   - pcre 8.37
   - openssl 1.0.1m
   - lua 5.2.4
   - distcache 1.5.1
   - libxml2 2.9.2

 - Tool chain:
 - platform gcc except for Solaris
   (gcc 4.1.2 for Solaris 8 and 4.9.2 for Solaris 10)
 - CFLAGS: -O2 -g -Wall -fno-strict-aliasing
   (and -mpcu=v9 on Solaris)

 All builds succeeded
   - one compiler warning
 server/mpm/event/event.c:1438: warning: 'last' may be used uninitialized
 in this function

 Tested for

 - Solaris 10 (32), SLES 10+11 (64), RHEL 6 (64)
 - MPMs prefork, worker, event
 - default (shared) and static modules
 - log levels info, debug and trace8
 - module set reallyall (121 modules plus MPMs)

 The following test failures were seen:

 a Test 4 or 5 in t/modules/dav.t:
   Happens for 33 out of 324 runs.
   Creation, modified and now times not in the correct order.
   This seems to be a system issue, all tests done on NFS,
   many tested on virtualized guests.
   Not a regression.

 b Various tests in t/apache/expr_string.t: (6, 11, 14, 17, 20 ,23)
   Happens for 65 out of 324 runs (almost all on SLES 10, 6 on RHEL6
   and 2 on Solaris).
   The failure is always on line 68, where the error_log contents
   are checked.
   Not a regression.

 c Tests 55-57 of t/modules/cgi.t testing contents of ScriptLog.
   The tests fail for reallyall modules.


Are both cgi and cgid loaded in the test config?  I saw 55-57 fail in that
situation.


   Likely similar than what I observed for 2.4.12.
   Fix probably by porting r1651085 from mod_cgi to mod_cgid.
   Not a regression.

 On FreeBSD I see the following failures:

 t/apache/limits.t (Wstat: 0 Tests: 12 Failed: 1)
   Failed test:  8


10.1: limits.t hangs for me after testing 7/12 if I have the kernel accept
filter loaded; passes fine otherwise

(presumably hang is just temporary, until the testcase is timed out)



 t/modules/aaa.t   (Wstat: 0 Tests: 40 Failed: 3)
   Failed tests:  23-24, 27


I don't see that with or without accept filter loaded


 t/ssl/pr12355.t   (Wstat: 0 Tests: 10 Failed: 4)
   Failed tests:  3-4, 7-8


ditto (tested only with accept filter unloaded)


 t/ssl/pr43738.t   (Wstat: 0 Tests: 4 Failed: 2)
   Failed tests:  1-2


ditto (tested only with accept filter unloaded)

My overall results with both prefork and event, no accept filter:

Test Summary Report
---
t/ssl/pr12355.t   (Wstat: 0 Tests: 10 Failed: 4)
  Failed tests:  3-4, 7-8
t/ssl/pr43738.t   (Wstat: 0 Tests: 4 Failed: 2)
  Failed tests:  1-2

I don't have a Lua lib installed; I don't see any other skips but PHP and
SSLv2.


 Since I don't have result from previous releases this is just for
 information.


2.4.12 on 10.1, no accept filter, event or prefork:

Test Summary Report
---
t/ssl/pr12355.t   (Wstat: 0 Tests: 10 Failed: 4)
  Failed tests:  3-4, 7-8
t/ssl/pr43738.t   (Wstat: 0 Tests: 4 Failed: 2)
  Failed tests:  1-2

If the kernel accept filter module is loaded, limits.t hangs.


[X] +1: Good to go


 Regards,

 Rainer




-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: TR of 2.4.13

[Jeff Trawick]

On Thu, Jun 4, 2015 at 10:30 AM, Jim Jagielski j...@jagunet.com wrote:

 Just a reminder... this is about 90mins from 'now'


Awesome/thanks!



  On Jun 2, 2015, at 7:32 AM, Jim Jagielski j...@jagunet.com wrote:
 
  Although there are some cool things that I'd like to see in
  2.4.13, I don't want to hold off any longer (plus, those
  cool things would be good incentive for a 2.4.14 sooner
  rather than later).
 
  I plan to TR 2.4.13 on Thurs, by Noon eastern.




-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: TR of 2.4.13

[Jeff Trawick]

On 06/02/2015 07:32 AM, Jim Jagielski wrote:

Although there are some cool things that I'd like to see in
2.4.13, I don't want to hold off any longer (plus, those
cool things would be good incentive for a 2.4.14 sooner
rather than later).

I plan to TR 2.4.13 on Thurs, by Noon eastern.


From a presentation last week to a Python user group: These slides 
refer to some small features introduced in httpd 2.4.13, which will be 
available very soon. ;)

Re: 2.2 and 2.4 and 2.6/3.0

[Jeff Trawick]

On Thu, May 28, 2015 at 3:45 PM, William A Rowe Jr wr...@rowe-clan.net
wrote:

 On May 27, 2015 9:46 AM, Jeff Trawick traw...@gmail.com wrote:
 
  On Wed, May 27, 2015 at 10:42 AM, Jeff Trawick traw...@gmail.com
 wrote:
 
  On Wed, May 27, 2015 at 8:54 AM, Jim Jagielski j...@jagunet.com wrote:
 
  Anyone else think it's time to EOL 2.2 and focus
  on 2.4 and the next gen? My thoughts are that http/2
  and mod_h2 will drive the trunk design efforts and so
  it would be nice to focus energy on 2.4 and later...
 
  People here focus their energy on whatever they want.  It takes a small
 number of people to keep a stable branch going (technically 3, but in
 practice a slightly higher number).  Instead of the group choosing EOL or
 only-security-fixes-of-some-minimal-severity or something else for a stable
 branch based on what many people think is interesting to them for whatever
 reason, I think that the project should limit its concern to ensuring that
 the community understands the state of the branch and that it is EOL-ed
 when a sufficient number of people don't care.
 
  actually, when a sufficient number of people don't care is what I'm
 arguing against :)  make that when an insufficient number of people care

 +1, well thought out, aligns with the historical commentary (just some of
 which I pointed out in the historical data points post)

  What we need to know for the 2.2.x branch is basically this:
 
  Developers (committers or not):
 
  [ X ] I am willing to help resolve security issues in the 2.2.x branch.
  [ X ] I am willing to help address non-security issues in the 2.2.x
 branch.
 
  PMC members:
 
  [ X ] I am willing to test and vote on proposed 2.2.x releases.

  (This is not a call for vote; I'm suggesting a very different mindset
 towards 2.2.x from nice to focus energy on and time to EOL 2.2 and focus
 on.)

 (:  Glad that others felt free to respond to this as a poll.

:)

The pseudo-poll was the clearest way I could think of to lay out my opinion
of what I think our criteria should be, and I didn't want to come across as
antagonistic anyway (random-emoticon)  But the several responses are useful
information.  Cut and paste at will!

I think there is a story in all of this for the greater community about our
(?) particular take on an open source project, pros and cons for

* individual developers
* different classes of users
* the httpd-of-Christmas-future,

our strong desire avoid unplanned obsolescence, our willingness to empower
even potentially small subsets of our developer community, etc.

(Meanwhile, somebody pinged me about mod_fcgid recently; apparently there
is some low-hanging fruit in Bugzilla and no any recent activity :( )

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: 2.2 and 2.4 and 2.6/3.0

[Jeff Trawick]

On Wed, May 27, 2015 at 10:42 AM, Jeff Trawick traw...@gmail.com wrote:

 On Wed, May 27, 2015 at 8:54 AM, Jim Jagielski j...@jagunet.com wrote:

 Anyone else think it's time to EOL 2.2 and focus
 on 2.4 and the next gen? My thoughts are that http/2
 and mod_h2 will drive the trunk design efforts and so
 it would be nice to focus energy on 2.4 and later...


 People here focus their energy on whatever they want.  It takes a small
 number of people to keep a stable branch going (technically 3, but in
 practice a slightly higher number).  Instead of the group choosing EOL or
 only-security-fixes-of-some-minimal-severity or something else for a stable
 branch based on what many people think is interesting to them for whatever
 reason, I think that the project should limit its concern to ensuring that
 the community understands the state of the branch and that it is EOL-ed
 when a sufficient number of people don't care.


actually, when a sufficient number of people don't care is what I'm
arguing against :)  make that when an insufficient number of people care



 What we need to know for the 2.2.x branch is basically this:

 Developers (committers or not):

 [  ] I am willing to help resolve security issues in the 2.2.x branch.
 [  ] I am willing to help address non-security issues in the 2.2.x branch.

 PMC members:

 [  ] I am willing to test and vote on proposed 2.2.x releases.

 Maybe this comes up to the same answer, maybe not.

 (This is not a call for vote; I'm suggesting a very different mindset
 towards 2.2.x from nice to focus energy on and time to EOL 2.2 and focus
 on.)

 --
 Born in Roswell... married an alien...
 http://emptyhammock.com/




-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: 2.2 and 2.4 and 2.6/3.0

[Jeff Trawick]

On Wed, May 27, 2015 at 8:54 AM, Jim Jagielski j...@jagunet.com wrote:

 Anyone else think it's time to EOL 2.2 and focus
 on 2.4 and the next gen? My thoughts are that http/2
 and mod_h2 will drive the trunk design efforts and so
 it would be nice to focus energy on 2.4 and later...


People here focus their energy on whatever they want.  It takes a small
number of people to keep a stable branch going (technically 3, but in
practice a slightly higher number).  Instead of the group choosing EOL or
only-security-fixes-of-some-minimal-severity or something else for a stable
branch based on what many people think is interesting to them for whatever
reason, I think that the project should limit its concern to ensuring that
the community understands the state of the branch and that it is EOL-ed
when a sufficient number of people don't care.

What we need to know for the 2.2.x branch is basically this:

Developers (committers or not):

[  ] I am willing to help resolve security issues in the 2.2.x branch.
[  ] I am willing to help address non-security issues in the 2.2.x branch.

PMC members:

[  ] I am willing to test and vote on proposed 2.2.x releases.

Maybe this comes up to the same answer, maybe not.

(This is not a call for vote; I'm suggesting a very different mindset
towards 2.2.x from nice to focus energy on and time to EOL 2.2 and focus
on.)

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: 2.2 and 2.4 and 2.6/3.0

[Jeff Trawick]

On Wed, May 27, 2015 at 12:32 PM, Jim Jagielski j...@jagunet.com wrote:

 My point is that if we EOL 2.2 (with some definition of EOL)
 then people on 2.2 (or earlier) will have some *real* incentive
 to move off of 2.2 towards 2.4 (or later)...

 Basically, we need something to kick people off 2.2
 and get them to 2.4. By stating that 2.2 will ONLY get
 security related fixes and no new features or improvements,
 and that 2.2 will be EOL by 201X, that will be encouragement.
 That, of course, assumes that we care one way or another
 about moving people to a more up-to-date and performant
 httpd, as well as whatever the future holds for httpd.

 FWIW: It was this month's PMC status report which kind of
   spurred this email.


crazy and not-so-crazy ideas will speed the movement to 2.4 irrespective of
distro schedules (not sure how much :) )

* something like this (and well-publicized) for every Linux distro:
https://launchpad.net/~ondrej/+archive/ubuntu/apache2
(I don't think I'm doing many people a favor if I show configure
invocations when I talk about 2.4; for most people it isn't a good idea to
build httpd themselves)
* upgrade Saturdays: IRC 2.2-2.4 upgrade events once a month  (not to say
that isn't available already, but maybe there are psychological aspects of
this that drive upgrade)
* compelling documentation of use cases that feature 2.4; e.g., full
deployment templates that include 2.4 as one part
better ideas here




  On May 27, 2015, at 11:34 AM, William A Rowe Jr wr...@rowe-clan.net
 wrote:
 
  On Wed, May 27, 2015 at 7:54 AM, Jim Jagielski j...@jagunet.com wrote:
  Anyone else think it's time to EOL 2.2 and focus
  on 2.4 and the next gen?
 
  Nope, we'll let the internet speak for itself -
 
  http://w3techs.com/technologies/history_details/ws-apache/2
 
  We are nowhere near close enough to the inflection point of that graph
 to justify starting the 12 month EOL clock (which has been our traditional
 countdown, same as the Tomcat project).
 
  My thoughts are that http/2
  and mod_h2 will drive the trunk design efforts and so
 
  That sounds about right.  I'm personally interested in 3.0 - refactoring
 on trunk to clean up the evolution of httpd since 2.0.36.  That was when we
 froze MMN majors, so many many bits are now shoehorned into the server in
 very awkward manners.  This will make backports to 2.4 more complex,
 however.
 
  it would be nice to focus energy on 2.4 and later...
 
  Focus your energy on anything you like.
 




-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: 2.2 and 2.4 and 2.6/3.0

[Jeff Trawick]

On Wed, May 27, 2015 at 1:19 PM, Jim Jagielski j...@jagunet.com wrote:

 
  crazy and not-so-crazy ideas will speed the movement to 2.4 irrespective
 of distro schedules (not sure how much :) )
 

 Here one: Since containers are the new hotness, how about being
 more Docker/Rocket/whatever friendly (whatever that means)? :)


one thing it means is having compelling stories involving the latest hot
tech that use 2.4

basically, any time there is a how-to-FOO somewhere on the www that uses
nginx for the web server component, there needs to be a better how-to-FOO
that uses httpd 2.4 ;)  (I don't even think 2.2 is an issue here)




 Hope making this suggestion is OK and that OtherBill doesn't think
 I'm BDFL posturing! *duck*




-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: 2.2 and 2.4 and 2.6/3.0

[Jeff Trawick]

On Wed, May 27, 2015 at 4:11 PM, Tim Bannister is...@c8h10n4o2.org.uk
wrote:

 On 27 May 2015, at 18:26, Jeff Trawick traw...@gmail.com wrote:
 
  one thing it means is having compelling stories involving the latest hot
 tech that use 2.4
 
  basically, any time there is a how-to-FOO somewhere on the www that uses
 nginx for the web server component, there needs to be a better how-to-FOO
 that uses httpd 2.4 ;)  (I don't even think 2.2 is an issue here)

 …same with forward- and reverse-proxying (Squid, Pound, Varnish, etc)

 Is the httpd wiki a good place to publish these?


conceptually yes, but the performance is so bad that you'll probably give
up



 --
 Tim Bannister – is...@c8h10n4o2.org.uk




-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: svn commit: r1681199 - /httpd/httpd/branches/2.4.x/STATUS

[Jeff Trawick]

On Fri, May 22, 2015 at 4:58 PM, Yann Ylavic ylavic@gmail.com wrote:

 Hi Jeff,

 On Fri, May 22, 2015 at 9:21 PM,  traw...@apache.org wrote:
 
  + trawick: It still looks to me that an error with ap_pass_brigade
 (towards
  +  client) can turn into a 400 error, which is what I was
 concerned
  +  about originally.

 I don't see where this can happen, but I may be missing something,
 please correct me if I'm wrong.

 Whenever ap_pass_brigade() is called, failing or not, the data_sent
 flag is set to 1 (some data have been sent to the client).
 Now outside the loop, in both cases where {client,backend}_failed
 (i.e. any read or write error occured on the {client,backend} side) or
 !request_ended (i.e. the last chunk was not received from the backend,
 yet another misnaming), the final rv will be set to DONE (and won't
 change until return, an error bucket 503 may be used if backend_failed
 but not if the client connection was aborted).


I see for fleeting moments that there's a sequence of setting of different
variables to certain values over the function that ensures that
HTTP_BAD_REQUEST is not set if an error occurred writing to the client.
Fun.

I'm sorry for the trouble.


 I agree that the state maintained by as much variables is a mess (the
 code has probably evolved by adding a new one to handle a new case, I
 did not add any in this patch though), and we ought to simplify this,
 but maybe we can leave it as is for 2.4.13 (and fix PR 56823) and
 refactor soon?
 I'd volonteer eventually...

 Regards,
 Yann.




-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: SSL/TLS best current practice

[Jeff Trawick]

On 05/06/2015 07:22 PM, William A Rowe Jr wrote:
Here is my proposed global config for httpd.conf.in 
http://httpd.conf.in for 2.4 and 2.2, which I believe mirrors the 
'MUST' of RFC 7525.


So new default configs are improved, and that's great.

Any joint interest in maintaining a guide to implementing SSL/TLS best 
practices in the documentation for those that don't normally see our 
latest/greatest default configuration and/or need some extra prose 
around it?


A start would be:

* list source material for best practices
* describe how known tradeoffs (such as blocking old clients) are 
accommodated in the specific configuration recommendations
* the actual configuration related to best SSL/TLS practices from our 
current default SSL configs
* hints on how to configure these in our past releases as well as with 
distributions that have their own idea of file layout/own defaults

Re: Platform specific CTR/RTC?

[Jeff Trawick]

On Fri, May 22, 2015 at 10:26 AM, Jim Jagielski j...@jagunet.com wrote:

 I think Bill's main point is that other than himself and
 gsmith, nobody else tests on MS/Win.


There might be others who test when something seems appropriate to them and
they have time ;)


 I tried, but I never got
 even to the point of getting it to even compile/build much
 less to a point where I could *test* :)


  On May 22, 2015, at 9:38 AM, Nick Kew n...@webthing.com wrote:
 
  On Fri, 22 May 2015 01:51:49 -0500
  William A Rowe Jr wr...@rowe-clan.net wrote:
 
 
  It might be worth mentioning that it's been in production for about 3-4
  years or so, and only was delayed in 2.2 due to the unavoidable drift
  between trunk/2.4 and 2.2 flavors.  We already included the
  ported-afterwards functionality in the previous 2.4.12 release, with
  apparently no issues.  The patch below is actually the origin of the
  enhancement.
 
  In those circumstances it seems not so much CTR or RTC but rather
  commonsense to go ahead.  Don't we have a bit of a history of
  struggling to meet RTC criteria on Windows-specific backports?
 
  I wonder if there's a case for formally adopting a lazy-consensus
  policy based on what wrowe is doing here?  If a proposal has sat in
  STATUS for a qualifying period, without attracting comment/
  reservations, but also without attracting sufficient review +1s,
  should it be eligible for lazy-consensus backport?
  The proponent posts here on a speak now or forever hold your peace
  basis, and goes ahead if no discussion calls it into question.
 
  --
  Nick Kew




-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Platform specific CTR/RTC?

[Jeff Trawick]

On Fri, May 22, 2015 at 2:51 AM, William A Rowe Jr wr...@rowe-clan.net
wrote:

 I think this has sat enough in STATUS that I'll commit by lazy consensus
 prior to tag and roll of 2.2.30, unless anyone has a legitimate
 correction/objection?


IMO it is appropriate to use CTR in the stable branches with
platform-specific code/build (where platform = Windows, NetWare, and other
non-Unix), and it is also nice/appropriate/whatever to give a heads up like
you did.


It might be worth mentioning that it's been in production for about 3-4
 years or so, and only was delayed in 2.2 due to the unavoidable drift
 between trunk/2.4 and 2.2 flavors.  We already included the
 ported-afterwards functionality in the previous 2.4.12 release, with
 apparently no issues.  The patch below is actually the origin of the
 enhancement.

* mpm_winnt service.c: Accept utf-8 service names/descriptions for i18n.
  trunk patches: http://svn.apache.org/r1611165
 http://svn.apache.org/r1611169
  2.2.x patch:
 http://people.apache.org/~wrowe/httpd-2.2-utf8-servicename.patch
  +1: wrowe, gsmith






-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Compiling httpd module for Windows

[Jeff Trawick]

On Fri, May 22, 2015 at 3:15 PM, Paul Klinkenberg p...@ongevraagdadvies.nl
wrote:

 Hi list members,

 I created a simple httpd module in C, called mod_cfml. It is a port of a
 Perl-based one, which was written by Jordan Michaels. I teamed up with him
 to do some updates and do the port.
  - original mod_cfml.PM:
 https://github.com/utdream/mod_cfml/blob/master/perl/mod_cfml.pm 
 https://github.com/utdream/mod_cfml/blob/master/perl/mod_cfml.pm
  - new mod_cfml.SO:
 https://github.com/paulklinkenberg/mod_cfml/blob/develop/C/mod_cfml.c 
 https://github.com/paulklinkenberg/mod_cfml/blob/develop/C/mod_cfml.c

 Reason I am writing to the list, is my inability to compile this module
 for Windows.  I am not a much experienced C coder, hope the code doesn't
 show that though. I tried multiple options, and spent over 16 hours in
 trying to get the module compiled on Windows. But to no avail.  On other
 platforms, I just use apxs, and it works like a charm.

 Bluntly asked: would somebody on this list be willing to compile this code
 for me/the project, for Apache 2.4 on Windows 32/64 bit? Or show me a
 working way how to do it myself?
 The project is 100% free opensource software, meant to help people, not to
 make money :)

 Thanks in advance, kind regards,

 Paul Klinkenberg


apxs for Windows: http://svn.apache.org/viewvc/perl/apxs/trunk/

I prefer cmake.  This should work reasonably if your httpd install looks
like the one installed with the cmake build:  (probably stuff is in the
right place)

If you try this and it works, let me know; I could put the generic one
(i.e., not cfml) on Github with a license and readme with a pointer in
the script.  I don't know if this is really enough code to have a license
for; my only concern is that I wouldn't want anyone to see this with some
other code and think that it is not free to use more widely than the code
they found it with.

- CMakeLists.txt --
PROJECT(MODS C)

CMAKE_MINIMUM_REQUIRED(VERSION 2.8)

SET(modnames cfml)

INCLUDE_DIRECTORIES(${CMAKE_INSTALL_PREFIX}/include)

FOREACH(shortname ${modnames})
SET(modbase mod_${shortname})
SET(modbasename ${modbase}.c)
ADD_LIBRARY(${modbase} SHARED ${modbasename})
SET_TARGET_PROPERTIES(${modbase} PROPERTIES SUFFIX .so)
TARGET_LINK_LIBRARIES(${modbase}
${CMAKE_INSTALL_PREFIX}/lib/libhttpd.lib
${CMAKE_INSTALL_PREFIX}/lib/libapr-1.lib
${CMAKE_INSTALL_PREFIX}/lib/libaprutil-1.lib)
INSTALL(TARGETS ${modbase} RUNTIME DESTINATION modules)
ENDFOREACH()
- end -

Put this CMakeLists.txt file in the directory with your source.

In MS Visual Studio command prompt:

mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=\path\to\httpd\install -G NMake Makefiles
-DCMAKE_BUILD_TYPE=RelWithDebInfo \path\to\your\source
nmake  nmake install

--/--
-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: svn commit: r1680895 - in /httpd/httpd/trunk: docs/manual/mod/mod_log_config.xml modules/loggers/mod_log_config.c

[Jeff Trawick]

On 05/21/2015 11:07 AM, rj...@apache.org wrote:

Author: rjung
Date: Thu May 21 15:07:15 2015
New Revision: 1680895

URL: http://svn.apache.org/r1680895
Log:
mod_log_config: instead of using the new dedicated
pattern format %M for duration milliseconds,
overload the existing %D to choose the time precision
(%{s}D for seconds, %{ms}D for milliseconds and
%{us}D for microseconds).

The existing %T and %D without precision are kept for
compatibility.

The previously introduced %M (r1677187) is removed,
it has not yet been released. Format pattern characters
are rare, so we should only use a new one if an
existing one isn't a good fit.

Modified:
 httpd/httpd/trunk/docs/manual/mod/mod_log_config.xml
 httpd/httpd/trunk/modules/loggers/mod_log_config.c

Modified: httpd/httpd/trunk/docs/manual/mod/mod_log_config.xml
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_log_config.xml?rev=1680895r1=1680894r2=1680895view=diff
==
--- httpd/httpd/trunk/docs/manual/mod/mod_log_config.xml (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_log_config.xml Thu May 21 15:07:15 
2015
@@ -95,6 +95,16 @@
  trtdcode%D/code/td
  tdThe time taken to serve the request, in microseconds./td/tr
  
+trtdcode%{varUNIT/var}D/code/td

+tdThe time taken to serve the request, in a time unit given by
+codeUNIT/code. Valid units are codems/code for milliseconds,
+codeus/code for microseconds and codes/code for seconds.
+Using codeus/code gives the same result as code%D/code
+without any format, using codes/code gives teh same result
+as code%T/code. Combining code%D/code with a unit is
+available in 2.4.13 and later./td/tr
+/td/tr
+
  trtdcode%{varVARNAME/var}e/code/td
  tdThe contents of the environment variable
  varVARNAME/var./td/tr
@@ -146,10 +156,6 @@
  trtdcode%m/code/td
  tdThe request method./td/tr
  
-trtdcode%M/code/td

-tdThe time taken to serve the request, in milliseconds.
-(available in 2.4.13 and later)/td/tr
-


This is a very nice improvement over introducing M, and Yann's 
suggestion to expand T instead of D is an increment above that.


Any concerns if I switch them out?


  trtdcode%{varVARNAME/var}n/code/td
  tdThe contents of note varVARNAME/var from another
  module./td/tr

Modified: httpd/httpd/trunk/modules/loggers/mod_log_config.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/loggers/mod_log_config.c?rev=1680895r1=1680894r2=1680895view=diff
==
--- httpd/httpd/trunk/modules/loggers/mod_log_config.c (original)
+++ httpd/httpd/trunk/modules/loggers/mod_log_config.c Thu May 21 15:07:15 2015
@@ -101,8 +101,10 @@
   * %...{format}t:  The time, in the form given by format, which should
   * be in strftime(3) format.
   * %...T:  the time taken to serve the request, in seconds.
- * %...M:  the time taken to serve the request, in milliseconds
   * %...D:  the time taken to serve the request, in micro seconds.
+ * %...{s}D:  the time taken to serve the request, in seconds, same as %T.
+ * %...{us}D:  the time taken to serve the request, in micro seconds, same as 
%D.
+ * %...{ms}D:  the time taken to serve the request, in milliseconds.
   * %...u:  remote user (from auth; may be bogus if return status (%s) is 401)
   * %...U:  the URL path requested.
   * %...v:  the configured name of the server (i.e. which virtual host?)
@@ -803,17 +805,22 @@ static const char *log_request_duration(
  return apr_psprintf(r-pool, % APR_TIME_T_FMT, apr_time_sec(duration));
  }
  
-static const char *log_request_duration_milliseconds(request_rec *r, char *a)

+static const char *log_request_duration_scaled(request_rec *r, char *a)
  {
  apr_time_t duration = get_request_end_time(r) - r-request_time;
-return apr_psprintf(r-pool, % APR_TIME_T_FMT, 
apr_time_as_msec(duration));
-}
-
-
-static const char *log_request_duration_microseconds(request_rec *r, char *a)
-{
-return apr_psprintf(r-pool, % APR_TIME_T_FMT,
-(get_request_end_time(r) - r-request_time));
+if (*a == '\0' || !strcasecmp(a, us)) {
+}
+else if (!strcasecmp(a, ms)) {
+duration = apr_time_as_msec(duration);
+}
+else if (!strcasecmp(a, s)) {
+duration = apr_time_sec(duration);
+}
+else {
+/* bogus format */
+return a;
+}
+return apr_psprintf(r-pool, % APR_TIME_T_FMT, duration);
  }
  
  /* These next two routines use the canonical name:port so that log

@@ -1844,8 +1851,7 @@ static int log_pre_config(apr_pool_t *p,
  log_pfn_register(p, C, log_cookie, 0);
  log_pfn_register(p, k, log_requests_on_connection, 0);
  log_pfn_register(p, r, log_request_line, 1);
-log_pfn_register(p, D, 

Re: svn commit: r1680895 - in /httpd/httpd/trunk: docs/manual/mod/mod_log_config.xml modules/loggers/mod_log_config.c

[Jeff Trawick]

On 05/21/2015 02:57 PM, Eric Covener wrote:

On Thu, May 21, 2015 at 2:54 PM, Jeff Trawick traw...@gmail.com wrote:

This is a very nice improvement over introducing M, and Yann's suggestion
to expand T instead of D is an increment above that.

Any concerns if I switch them out?

+1 here

done; now fixing up a 2.4.x patch to match...

Re: silly ab patch for SNI and OCSP stapling

[Jeff Trawick]

On Sat, May 16, 2015 at 10:39 AM, Daniel Ruggeri drugg...@primary.net
wrote:

 +1, but I would also propose a command line flag to override the SNI host
 name supplied in case one is testing directly by IP address.


in that case shouldn't you also be overriding Host:, so the SNI host name
can use the same override?  I think this may lead the user into a more
helpful scenario, if indeed they don't already know when to override Host:,
and I don't know how useful it is to have different values for Host: and
SNI.



 --
 Daniel Ruggeri

 --
 *From:* Jeff Trawick traw...@gmail.com
 *Sent:* May 12, 2015 2:31:37 PM CDT
 *To:* Apache HTTP Server Development List dev@httpd.apache.org
 *Subject:* silly ab patch for SNI and OCSP stapling

 ... where OCSP stapling means get the server to do the related work
 but don't care what you get back.

 Perhaps this doesn't save any time for anybody that would want to test
 such a thing, but who knows?

 Index: support/ab.c
 --

 --- support/ab.c(revision 1679028)
 +++ support/ab.c(working copy)
 @@ -1287,6 +1287,8 @@
   bio = BIO_new_socket(fd, BIO_NOCLOSE);
   SSL_set_bio(c-ssl, bio, bio);
   SSL_set_connect_state(c-ssl);
 +SSL_set_tlsext_host_name(c-ssl, hostname);
 +SSL_set_tlsext_status_type(c-ssl, TLSEXT_STATUSTYPE_ocsp);
   if (verbosity = 4) {
   BIO_set_callback(bio, ssl_print_cb);
   BIO_set_callback_arg(bio, (void *)bio_err);

 The lack of SNI is a pretty big hole now; it probably doesn't need much
 extra in the way of #if/if to do the right thing.




-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: SO_REUSEPORT

[Jeff Trawick]

On Fri, May 15, 2015 at 11:02 AM, William A Rowe Jr wr...@rowe-clan.net
wrote:

 My chief concern was that the phrase Common Log has a specific meaning
 to us.

 ap_mpm_common_log_startup() or something else descriptive would be a
 better name, but our crew is famous for not being terrific namers of things
 :)

 Did this compile with no warnings?  It seems statics were used without
 being explicitly initialized, and I don't have my copy of KR to check that
 these are always NULL, but guessing that's so.


yes; but ISTR that NetWare is the reason for explicit initialization in
some of our multi-platform code; I dunno the rhyme



   For clarity alone, I'd prefer these were initialized like every other
 example they were adjacent to.




 On Fri, May 15, 2015 at 7:06 AM, Jim Jagielski j...@jagunet.com wrote:

 We are very close... I believe wrowe has some somewhat trivial
 reservations about it, but we are awaiting 1 more vote.

 Someone want to address wrowes concerns on trunk and patch
 the patch (stuff like naming)? I may have time next week.

  On May 14, 2015, at 7:45 PM, Yann Ylavic ylavic@gmail.com wrote:
 
  Hi Yingqi,
 
  2 votes already (on 3), it makes its way ;)
 
  Regards,
  Yann.
 
 
  On Fri, May 15, 2015 at 1:00 AM, Lu, Yingqi yingqi...@intel.com
 wrote:
  Hi All,
 
  I just want to check if anyone gets chances to check the SO_REUSEPORT
 patch? Any feedback?
 
  Thanks,
  Yingqi
 
  -Original Message-
  From: Lu, Yingqi [mailto:yingqi...@intel.com]
  Sent: Friday, May 08, 2015 8:58 AM
  To: dev@httpd.apache.org
  Subject: RE: SO_REUSEPORT
 
  Hi Christophe, Jim and Yann,
 
  Thank you very much for your consideration of putting SO_REUSEPORT
 patch in the 2.4 stable release.
 
  I am also very happy that you find the white paper :-) All the most
 recent testing results are included in the white paper. Also, we have
 tested the (graceful) restart on the patch (previously, there was a bug.),
 it should be fine now. Please test it to confirm.
 
  Please let me know if you need anything else. Your help is appreciated.
 
  Thanks,
  Yingqi
 
  -Original Message-
  From: Yann Ylavic [mailto:ylavic@gmail.com]
  Sent: Friday, May 08, 2015 5:02 AM
  To: httpd
  Subject: Re: SO_REUSEPORT
 
  On Fri, May 8, 2015 at 9:44 AM, Christophe JAILLET 
 christophe.jail...@wanadoo.fr wrote:
 
  Maybe, 2.4.14 could focus on reviewing/merging this patch and
  associated performance improvement?
  To help adoption, maybe an ASF server could be upgraded with a
  SO_REUSEPORT patched version of Apache to have our own measurements
  and see how it scales in a real world application.
 
  I did some testing with an injector at the time of the proposal (on a
 2.2.x version of the patch, so mainly with worker), and can confirm that it
 really scales much better.
  Where httpd without SO_REUSEPORT stops accepting/handling connections,
 it continues to shine with the option/buckets enabled.
  (I don't have the numbers for now, need to search deeper, btw the ones
 from Intel are probably more of interest...)
 
  So regarding the upgrade on infra, the difference may not be obvious
 if the tested machine is not at the limits.
 
  One thing that probably is worth testing is (graceful) restarts,
 though.
 
  Regards,
  Yann.





-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: svn commit: r1679032 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_ssl.xml modules/ssl/mod_ssl.c modules/ssl/ssl_engine_config.c modules/ssl/ssl_private.h modules/ssl/ssl_util_stapling.c

[Jeff Trawick]

On 05/12/2015 04:50 PM, Jeff Trawick wrote:

On 05/12/2015 03:32 PM, Yann Ylavic wrote:

On Tue, May 12, 2015 at 8:59 PM, traw...@apache.org wrote:

Author: trawick
Date: Tue May 12 18:59:29 2015
New Revision: 1679032

URL: http://svn.apache.org/r1679032
Log:
mod_ssl OCSP Stapling: Don't block initial handshakes while refreshing
the OCSP response for a different certificate.  mod_ssl has an 
additional

global mutex, ssl-stapling-refresh.


[]

Modified: httpd/httpd/trunk/modules/ssl/ssl_util_stapling.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_util_stapling.c?rev=1679032r1=1679031r2=1679032view=diff
== 


--- httpd/httpd/trunk/modules/ssl/ssl_util_stapling.c (original)
+++ httpd/httpd/trunk/modules/ssl/ssl_util_stapling.c Tue May 12 
18:59:29 2015

[]

+
+static int get_and_check_cached_response(server_rec *s, 
modssl_ctx_t *mctx,
+ OCSP_RESPONSE **rsp, BOOL 
*ok,
+ certinfo *cinf, apr_pool_t 
*p)

+{
+int rv;
+
+/* Check to see if we already have a response for this 
certificate */

+rv = stapling_get_cached_response(s, rsp, ok, cinf, p);
+if (rv == FALSE) {
+return SSL_TLSEXT_ERR_ALERT_FATAL;
+}
+
+if (*rsp) {
+/* see if response is acceptable */
+ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s, APLOGNO(01953)
+ stapling_cb: retrieved cached response);
+rv = stapling_check_response(s, mctx, cinf, *rsp, NULL);
+if (rv == SSL_TLSEXT_ERR_ALERT_FATAL) {
+OCSP_RESPONSE_free(*rsp);
+return SSL_TLSEXT_ERR_ALERT_FATAL;
+}
+else if (rv == SSL_TLSEXT_ERR_NOACK) {
+/* Error in response. If this error was not present 
when it was

+ * stored (i.e. response no longer valid) then it can be
+ * renewed straight away.
+ *
+ * If the error *was* present at the time it was stored 
then we
+ * don't renew the response straight away; we just wait 
for the

+ * cached response to expire.
+ */
+if (ok) {

if (*ok) ?
Or maybe 'ok' shouldn't be a pointer (not updated here)?


Thanks a bunch!  I'll sort it out tomorrow 


r1679192


and make sure I'm testing more paths.


TBD :)

Thanks again!




+ OCSP_RESPONSE_free(*rsp);
+*rsp = NULL;
+}
+else if (!mctx-stapling_return_errors) {
+OCSP_RESPONSE_free(*rsp);
+return SSL_TLSEXT_ERR_NOACK;
+}
+}
+}
+return 0;
+}
+

Regards,
Yann.

Re: svn commit: r1679032 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_ssl.xml modules/ssl/mod_ssl.c modules/ssl/ssl_engine_config.c modules/ssl/ssl_private.h modules/ssl/ssl_util_stapling.c

[Jeff Trawick]

On 05/13/2015 08:59 AM, Yann Ylavic wrote:

On Wed, May 13, 2015 at 2:34 PM, Jeff Trawick traw...@gmail.com wrote:

Thanks again!

You're welcome ;)

WDYT of the following?
(cosmetic only, but helps read/reuse-ability a bit)

Index: modules/ssl/ssl_util_stapling.c
===
--- modules/ssl/ssl_util_stapling.c(revision 1679195)
+++ modules/ssl/ssl_util_stapling.c(working copy)
@@ -250,13 +250,11 @@ static BOOL stapling_cache_response(server_rec *s,

  i2d_OCSP_RESPONSE(rsp, p);

-if (mc-stapling_cache-flags  AP_SOCACHE_FLAG_NOTMPSAFE)
-stapling_cache_mutex_on(s);
+stapling_cache_mutex_on(s);
  rv = mc-stapling_cache-store(mc-stapling_cache_context, s,
 cinf-idx, sizeof(cinf-idx),
 expiry, resp_der, stored_len, pool);
-if (mc-stapling_cache-flags  AP_SOCACHE_FLAG_NOTMPSAFE)
-stapling_cache_mutex_off(s);
+stapling_cache_mutex_off(s);


At the moment I very slightly prefer seeing the reminder that there 
isn't always a mutex, but I won't care before long.  I prefer that this 
matches the implementation of the session cache mutex on where the 
socache flag is checked, but if it makes you happy and you change the 
session cache equivalent to match then go for it :)



  if (rv != APR_SUCCESS) {
  ap_log_error(APLOG_MARK, APLOG_ERR, 0, s, APLOGNO(01929)
   stapling_cache_response: OCSP response session
store error!);
@@ -277,13 +275,11 @@ static BOOL stapling_get_cached_response(server_re
  const unsigned char *p;
  unsigned int resp_derlen = MAX_STAPLING_DER;

-if (mc-stapling_cache-flags  AP_SOCACHE_FLAG_NOTMPSAFE)
-stapling_cache_mutex_on(s);
+stapling_cache_mutex_on(s);
  rv = mc-stapling_cache-retrieve(mc-stapling_cache_context, s,
cinf-idx, sizeof(cinf-idx),
resp_der, resp_derlen, pool);
-if (mc-stapling_cache-flags  AP_SOCACHE_FLAG_NOTMPSAFE)
-stapling_cache_mutex_off(s);
+stapling_cache_mutex_off(s);
  if (rv != APR_SUCCESS) {
  ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s, APLOGNO(01930)
   stapling_get_cached_response: cache miss);
@@ -623,8 +619,11 @@ static int stapling_cache_mutex_on(server_rec *s)
  {
  SSLModConfigRec *mc = myModConfig(s);

-return stapling_mutex_on(s, mc-stapling_cache_mutex,
- SSL_STAPLING_CACHE_MUTEX_TYPE);
+if (mc-stapling_cache-flags  AP_SOCACHE_FLAG_NOTMPSAFE) {
+return stapling_mutex_on(s, mc-stapling_cache_mutex,
+ SSL_STAPLING_CACHE_MUTEX_TYPE);
+}
+return TRUE;
  }

  static int stapling_cache_mutex_off(server_rec *s)
@@ -631,8 +630,11 @@ static int stapling_cache_mutex_off(server_rec *s)
  {
  SSLModConfigRec *mc = myModConfig(s);

-return stapling_mutex_off(s, mc-stapling_cache_mutex,
-  SSL_STAPLING_CACHE_MUTEX_TYPE);
+if (mc-stapling_cache-flags  AP_SOCACHE_FLAG_NOTMPSAFE) {
+return stapling_mutex_off(s, mc-stapling_cache_mutex,
+  SSL_STAPLING_CACHE_MUTEX_TYPE);
+}
+return TRUE;
  }

  static int stapling_refresh_mutex_on(server_rec *s)
--

Re: Solving mutex concerns with OCSP stapling

[Jeff Trawick]

On 05/06/2015 08:19 PM, Jeff Trawick wrote:

On 05/03/2015 09:58 PM, Jeff Trawick wrote:

Your thoughts on the following?

Current OCSP behavior that I think needs to be fixed:

mod_ssl holds the single stapling global mutex when looking up a 
cached entry,
deserializing it, checking validity, and (when missing/expired) 
communicating

with the OCSP responder to get a new response.

1. mod_ssl shouldn't hold the single stapling global mutex when 
talking to
   the OCSP responder.  This will stall ALL initial handshakes in all 
stapling-

   enabled vhosts, regardless of the certificate they use.
2. For the cache itself, mod_ssl shouldn't hold the single stapling 
global
   mutex when looking up a cached entry unless the socache type 
requires it

   for its own purposes.  (memcached and distcache do not require it.)

Assumption: The cache can be shared among different httpd instances 
(e.g., via
memcached) but getting different instances to agree on which instance 
refreshes
the cache is not worth handling for now.  (Let multiple instances 
refresh if

the timing is unlucky.)

What must be serialized globally within an httpd instance?

1. If the socache provider requires it: Any access to the stapling 
cache.

2. A thread claiming responsibility for refreshing the cached entry.

Why no global mutex per certificate?

1. There could be a large number of certificates, and lots of global 
mutexes
could be very surprising or even require OS tuning with some mutex 
types.
2. A single mutex is required to interact with the cache anyway (when 
the

cache requires a mutex).
3. That doesn't resolve the decision of which thread fetches a new 
response

anyway.

Solution A: Prefetching in a daemon process/thread per httpd instance

The request processing flow would be most unlikely to block for stapling
if a daemon is responsible for maintaining the cache and the request 
thread
never has to look anything up.  That leaves a race between 
prefetching the

first time and requests hitting the server right after server startup.
(Browsers may report an error to the user when tryLater is returned.)

The daemon would try to renew stapling responses ahead of the time that
the existing response could no longer be used.  If it can't, the error
path on the request thread would be the same as the current handling of
an inability to fetch a new response.

Solution B: Fetch on demand largely like current code, but utilize a 
separate Fetch mutex


Hold the stapling cache mutex just while reading from/writing to the
cache; grab the Fetch mutex when needing to perform a lookup.
(Once obtaining the Fetch mutex, you'd need to look in the cache again
to see if another request thread did the lookup/store while waiting
for the Fetch mutex.)

By itself this doesn't solve potentially blocking a bunch of initial
handshakes when performing a lookup, but at least it solves blocking
requests that already have a cached response (different certificate)
when performing a lookup.

A fairly simple improvement to this would be to have a small number
of Fetch mutexes, where each certificate maps to a specific fetch
mutex (but not vice versa), so that lookups for multiple certificates
could be done at once.  This doesn't solve blocking all initial
handshakes for a certificate that needs a fresh response, or completely
solve blocking those for other certificates that need a fresh response
(since multiple certificates could map to the same Fetch mutex).

Solution C: Hybrid of A and B

The request thread implements solution B but generally a lookup on
the request thread won't be needed since the daemon has already done
the work.  But at server startup the daemon and the request threads
might fight over the Fetch mutex until responses for commonly-used
certificates had been obtained/cached.  This solves a potential lack
of responses at server startup.

Since the request thread is able to do the work in a pinch, this
lends itself to a SSLStaplingPrefetch On|Off directive that could
be used to disable the prefetch daemon.



FWIW I'm just testing solution B for the moment.  I think that the 
ability to prefetch is needed for the busiest sites to avoid weird 
pileups, but B seems necessary anyway.


r1679032 implements Plan B, without using multiple Fetch mutexes.

Some further thoughts:

Alternative to Plan A for prefetching: A request thread realizes that 
stapling response will expire soon, claims responsibility for 
refreshing it so that other request threads don't do so, and does the 
work; this avoids another execution thread to perform the prefetch.  
Somehow claiming responsibility seems like it will add its own 
complication (need stapling cache entry type at front of cert-based 
cache key, and one type is response and another type is refresh 
responsibility???).  r1679032 would still be used when this isn't done, 
such as when there isn't demand in time (e.g., mass vhosting, for some 
value of mass).


Plan A could presumably use some mod_daemon

silly ab patch for SNI and OCSP stapling

[Jeff Trawick]

... where OCSP stapling means get the server to do the related work 
but don't care what you get back.


Perhaps this doesn't save any time for anybody that would want to test 
such a thing, but who knows?


Index: support/ab.c
===
--- support/ab.c(revision 1679028)
+++ support/ab.c(working copy)
@@ -1287,6 +1287,8 @@
 bio = BIO_new_socket(fd, BIO_NOCLOSE);
 SSL_set_bio(c-ssl, bio, bio);
 SSL_set_connect_state(c-ssl);
+SSL_set_tlsext_host_name(c-ssl, hostname);
+SSL_set_tlsext_status_type(c-ssl, TLSEXT_STATUSTYPE_ocsp);
 if (verbosity = 4) {
 BIO_set_callback(bio, ssl_print_cb);
 BIO_set_callback_arg(bio, (void *)bio_err);

The lack of SNI is a pretty big hole now; it probably doesn't need much 
extra in the way of #if/if to do the right thing.

Re: svn commit: r1679032 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_ssl.xml modules/ssl/mod_ssl.c modules/ssl/ssl_engine_config.c modules/ssl/ssl_private.h modules/ssl/ssl_util_stapling.c

[Jeff Trawick]

On 05/12/2015 03:32 PM, Yann Ylavic wrote:

On Tue, May 12, 2015 at 8:59 PM,  traw...@apache.org wrote:

Author: trawick
Date: Tue May 12 18:59:29 2015
New Revision: 1679032

URL: http://svn.apache.org/r1679032
Log:
mod_ssl OCSP Stapling: Don't block initial handshakes while refreshing
the OCSP response for a different certificate.  mod_ssl has an additional
global mutex, ssl-stapling-refresh.


[]

Modified: httpd/httpd/trunk/modules/ssl/ssl_util_stapling.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_util_stapling.c?rev=1679032r1=1679031r2=1679032view=diff
==
--- httpd/httpd/trunk/modules/ssl/ssl_util_stapling.c (original)
+++ httpd/httpd/trunk/modules/ssl/ssl_util_stapling.c Tue May 12 18:59:29 2015

[]

+
+static int get_and_check_cached_response(server_rec *s, modssl_ctx_t *mctx,
+ OCSP_RESPONSE **rsp, BOOL *ok,
+ certinfo *cinf, apr_pool_t *p)
+{
+int rv;
+
+/* Check to see if we already have a response for this certificate */
+rv = stapling_get_cached_response(s, rsp, ok, cinf, p);
+if (rv == FALSE) {
+return SSL_TLSEXT_ERR_ALERT_FATAL;
+}
+
+if (*rsp) {
+/* see if response is acceptable */
+ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s, APLOGNO(01953)
+ stapling_cb: retrieved cached response);
+rv = stapling_check_response(s, mctx, cinf, *rsp, NULL);
+if (rv == SSL_TLSEXT_ERR_ALERT_FATAL) {
+OCSP_RESPONSE_free(*rsp);
+return SSL_TLSEXT_ERR_ALERT_FATAL;
+}
+else if (rv == SSL_TLSEXT_ERR_NOACK) {
+/* Error in response. If this error was not present when it was
+ * stored (i.e. response no longer valid) then it can be
+ * renewed straight away.
+ *
+ * If the error *was* present at the time it was stored then we
+ * don't renew the response straight away; we just wait for the
+ * cached response to expire.
+ */
+if (ok) {

if (*ok) ?
Or maybe 'ok' shouldn't be a pointer (not updated here)?


Thanks a bunch!  I'll sort it out tomorrow and make sure I'm testing 
more paths.





+OCSP_RESPONSE_free(*rsp);
+*rsp = NULL;
+}
+else if (!mctx-stapling_return_errors) {
+OCSP_RESPONSE_free(*rsp);
+return SSL_TLSEXT_ERR_NOACK;
+}
+}
+}
+return 0;
+}
+

Regards,
Yann.

Re: Solving mutex concerns with OCSP stapling

[Jeff Trawick]

On 05/03/2015 09:58 PM, Jeff Trawick wrote:

Your thoughts on the following?

Current OCSP behavior that I think needs to be fixed:

mod_ssl holds the single stapling global mutex when looking up a 
cached entry,
deserializing it, checking validity, and (when missing/expired) 
communicating

with the OCSP responder to get a new response.

1. mod_ssl shouldn't hold the single stapling global mutex when 
talking to
   the OCSP responder.  This will stall ALL initial handshakes in all 
stapling-

   enabled vhosts, regardless of the certificate they use.
2. For the cache itself, mod_ssl shouldn't hold the single stapling global
   mutex when looking up a cached entry unless the socache type 
requires it

   for its own purposes.  (memcached and distcache do not require it.)

Assumption: The cache can be shared among different httpd instances 
(e.g., via
memcached) but getting different instances to agree on which instance 
refreshes
the cache is not worth handling for now.  (Let multiple instances 
refresh if

the timing is unlucky.)

What must be serialized globally within an httpd instance?

1. If the socache provider requires it: Any access to the stapling cache.
2. A thread claiming responsibility for refreshing the cached entry.

Why no global mutex per certificate?

1. There could be a large number of certificates, and lots of global 
mutexes

could be very surprising or even require OS tuning with some mutex types.
2. A single mutex is required to interact with the cache anyway (when the
cache requires a mutex).
3. That doesn't resolve the decision of which thread fetches a new 
response

anyway.

Solution A: Prefetching in a daemon process/thread per httpd instance

The request processing flow would be most unlikely to block for stapling
if a daemon is responsible for maintaining the cache and the request 
thread

never has to look anything up.  That leaves a race between prefetching the
first time and requests hitting the server right after server startup.
(Browsers may report an error to the user when tryLater is returned.)

The daemon would try to renew stapling responses ahead of the time that
the existing response could no longer be used.  If it can't, the error
path on the request thread would be the same as the current handling of
an inability to fetch a new response.

Solution B: Fetch on demand largely like current code, but utilize a 
separate Fetch mutex


Hold the stapling cache mutex just while reading from/writing to the
cache; grab the Fetch mutex when needing to perform a lookup.
(Once obtaining the Fetch mutex, you'd need to look in the cache again
to see if another request thread did the lookup/store while waiting
for the Fetch mutex.)

By itself this doesn't solve potentially blocking a bunch of initial
handshakes when performing a lookup, but at least it solves blocking
requests that already have a cached response (different certificate)
when performing a lookup.

A fairly simple improvement to this would be to have a small number
of Fetch mutexes, where each certificate maps to a specific fetch
mutex (but not vice versa), so that lookups for multiple certificates
could be done at once.  This doesn't solve blocking all initial
handshakes for a certificate that needs a fresh response, or completely
solve blocking those for other certificates that need a fresh response
(since multiple certificates could map to the same Fetch mutex).

Solution C: Hybrid of A and B

The request thread implements solution B but generally a lookup on
the request thread won't be needed since the daemon has already done
the work.  But at server startup the daemon and the request threads
might fight over the Fetch mutex until responses for commonly-used
certificates had been obtained/cached.  This solves a potential lack
of responses at server startup.

Since the request thread is able to do the work in a pinch, this
lends itself to a SSLStaplingPrefetch On|Off directive that could
be used to disable the prefetch daemon.



FWIW I'm just testing solution B for the moment.  I think that the 
ability to prefetch is needed for the busiest sites to avoid weird 
pileups, but B seems necessary anyway.



--
Born in Roswell... married an alien...
http://emptyhammock.com/

Solving mutex concerns with OCSP stapling

[Jeff Trawick]

Your thoughts on the following?

Current OCSP behavior that I think needs to be fixed:

mod_ssl holds the single stapling global mutex when looking up a cached
entry,
deserializing it, checking validity, and (when missing/expired)
communicating
with the OCSP responder to get a new response.

1. mod_ssl shouldn't hold the single stapling global mutex when talking to
   the OCSP responder.  This will stall ALL initial handshakes in all
stapling-
   enabled vhosts, regardless of the certificate they use.
2. For the cache itself, mod_ssl shouldn't hold the single stapling global
   mutex when looking up a cached entry unless the socache type requires it
   for its own purposes.  (memcached and distcache do not require it.)

Assumption: The cache can be shared among different httpd instances (e.g.,
via
memcached) but getting different instances to agree on which instance
refreshes
the cache is not worth handling for now.  (Let multiple instances refresh if
the timing is unlucky.)

What must be serialized globally within an httpd instance?

1. If the socache provider requires it: Any access to the stapling cache.
2. A thread claiming responsibility for refreshing the cached entry.

Why no global mutex per certificate?

1. There could be a large number of certificates, and lots of global mutexes
could be very surprising or even require OS tuning with some mutex types.
2. A single mutex is required to interact with the cache anyway (when the
cache requires a mutex).
3. That doesn't resolve the decision of which thread fetches a new response
anyway.

Solution A: Prefetching in a daemon process/thread per httpd instance

The request processing flow would be most unlikely to block for stapling
if a daemon is responsible for maintaining the cache and the request thread
never has to look anything up.  That leaves a race between prefetching the
first time and requests hitting the server right after server startup.
(Browsers may report an error to the user when tryLater is returned.)

The daemon would try to renew stapling responses ahead of the time that
the existing response could no longer be used.  If it can't, the error
path on the request thread would be the same as the current handling of
an inability to fetch a new response.

Solution B: Fetch on demand largely like current code, but utilize a
separate Fetch mutex

Hold the stapling cache mutex just while reading from/writing to the
cache; grab the Fetch mutex when needing to perform a lookup.
(Once obtaining the Fetch mutex, you'd need to look in the cache again
to see if another request thread did the lookup/store while waiting
for the Fetch mutex.)

By itself this doesn't solve potentially blocking a bunch of initial
handshakes when performing a lookup, but at least it solves blocking
requests that already have a cached response (different certificate)
when performing a lookup.

A fairly simple improvement to this would be to have a small number
of Fetch mutexes, where each certificate maps to a specific fetch
mutex (but not vice versa), so that lookups for multiple certificates
could be done at once.  This doesn't solve blocking all initial
handshakes for a certificate that needs a fresh response, or completely
solve blocking those for other certificates that need a fresh response
(since multiple certificates could map to the same Fetch mutex).

Solution C: Hybrid of A and B

The request thread implements solution B but generally a lookup on
the request thread won't be needed since the daemon has already done
the work.  But at server startup the daemon and the request threads
might fight over the Fetch mutex until responses for commonly-used
certificates had been obtained/cached.  This solves a potential lack
of responses at server startup.

Since the request thread is able to do the work in a pinch, this
lends itself to a SSLStaplingPrefetch On|Off directive that could
be used to disable the prefetch daemon.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release APR 1.5.2

[Jeff Trawick]

On 04/28/2015 12:18 PM, Eric Covener wrote:

On Sat, Apr 25, 2015 at 8:13 AM, Jeff Trawick traw...@gmail.com wrote:

+/-1
[  ] Release APR 1.5.2 as GA


+1 for release.  Tested on AIX/PPC32, HPUX/IA64 and Solaris/x64.

HPUX and AIX had non-regression long standing failure in testxlate.
Can you respond on the dev@apr thread?  This was just bait for people 
with their phone activated in their pocket :)

Re: [VOTE] Release APR 1.5.2

[Jeff Trawick]

On Sat, Apr 25, 2015 at 9:37 AM, Yann Ylavic ylavic@gmail.com wrote:

 Hi Jeff,

 shouldn't this be addressed to dev@apr instead?


yes, of course :)



 On Sat, Apr 25, 2015 at 2:13 PM, Jeff Trawick traw...@gmail.com wrote:
  Tarballs/zipfiles are at http://apr.apache.org/dev/dist/
 
  Shortcut to CHANGES:
  http://apr.apache.org/dev/dist/CHANGES-APR-1.5.2
 
  autoconf version: 2.69 (same as apr 1.5.1)
  libtool version: 2.4.2 (same as apr 1.5.1)
 
  +/-1
  [  ] Release APR 1.5.2 as GA
 
  I'll hold the vote open for 72 hours unless something out of the ordinary
  occurs.
 
  Thanks in advance for testing!
 




-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

[VOTE] Release APR 1.5.2

[Jeff Trawick]

Tarballs/zipfiles are at http://apr.apache.org/dev/dist/

Shortcut to CHANGES:
http://apr.apache.org/dev/dist/CHANGES-APR-1.5.2

autoconf version: 2.69 (same as apr 1.5.1)
libtool version: 2.4.2 (same as apr 1.5.1)

+/-1
[  ] Release APR 1.5.2 as GA

I'll hold the vote open for 72 hours unless something out of the 
ordinary occurs.


Thanks in advance for testing!

Re: trunk and FreeBSD 10.1

[Jeff Trawick]

On 04/23/2015 11:59 AM, Jim Jagielski wrote:

Hmmm... I am seeing some strangeness trying to get trunk to
build on FreeBSD 10.1... I get to ./server/ and then the
build dies w/


try gmake?

IIRC I had noticed that some BSD make compatibility was lost at some 
point...


-DCROSS_COMPILE -o gen_test_char
make[2]: exec(-DCROSS_COMPILE) failed (No such file or directory)
*** Error code 1

It looks like the Makefile.in-Makefile process is causing issues.
This is what I get in the Makefile:


.include $(top_builddir)/build/rules.mk
.include $(top_srcdir)/build/library.mk

.ifdef CC_FOR_BUILD
gen_test_char: gen_test_char.c
$(CC_FOR_BUILD) $(CFLAGS_FOR_BUILD) -DCROSS_COMPILE -o $@ $
.else
gen_test_char_OBJECTS = gen_test_char.lo
gen_test_char: $(gen_test_char_OBJECTS)
$(LINK) $(EXTRA_LDFLAGS) $(gen_test_char_OBJECTS) $(EXTRA_LIBS)
.endif

So we can see where the error is... those shell vars aren't
defined/found. But why?