Re: release roll soon?

[Gregg Smith]

Since OpenSSL 3.0.0 GA came out yesterday (Californuts time) I think it 
would be nice to have r1891138 backported for those wishing to try it 
out. What you say?


Cheers,

Gregg

Re: [VOTE] Release httpd-2.4.46

[Gregg Smith]

On 8/1/2020 7:13 AM, Daniel Ruggeri wrote:

Hi, all;
    Third time is a charm! Please find below the proposed release tarball
and signatures:
https://dist.apache.org/repos/dist/dev/httpd/

I would like to call a VOTE over the next few days to release this
candidate tarball as 2.4.46:
[ ] +1: It's not just good, it's good enough!
[ ] +0: Let's have a talk.
[ ] -1: There's trouble in paradise. Here's what's wrong.

The computed digests of the tarball up for vote are:
sha1: 15adb7eb3dc97e89c8a4237901a9d6887056ab98 *httpd-2.4.46.tar.gz
sha256: 44b759ce932dc090c0e75c0210b4485ebf6983466fb8ca1b446c8168e1a1aec2
*httpd-2.4.46.tar.gz
sha512:
5801c1dd0365f706a5e2365e58599b5adac674f3c66b0f39249909841e6cdf16bfdfe001fbd668f323bf7b6d14b116b5e7af49867d456336fad5e685ba020b15
*httpd-2.4.46.tar.gz

The SVN tag is '2.4.46' at r1880505.


+1 on Windows VS15 & 16 built at command line.

Re: Trunk errors

[Gregg Smith]

Hi Steffen,


Assuming your building in the IDE as I know to be your usual;

On 5/8/2020 4:59 AM, Steffen wrote:



Tried revision 1877505.

libhttpd :
miss in trunk modules\http\http_etag.c. Moved the one from Branches to 
include, libhttpd builds then, is that ok ?


Yes to get it to build for now. Question is why isn't it in trunk, 
modules/http like it is in branches or anywhere (quick look and I can't 
see it).



mod_cache :
#include "test_char.h"  not found.  Copied the generated 
server/test_char.h to /include, mod_cache builds then, is that ok ?


Yes to get it to build for now. We may just need to change the location 
it's generated to, or just point to it's location in the build. If it's 
not a public header then we do the second option. I'll look at that.



htdbm and htpasswd :
support\passwd_common.h(31,10): fatal error C1083: Cannot open include 
file: 'ap_config_auto.h': No such file or directory.


This gives me a deja vu feeling with what stopped mod_ssl from building 
in 2.4.42. The winbuilds dsp/mak files generate headers by copying a 
.h.in file of the same name like ap_config_layout.h.in. This deja vu 
feeling tells me just feeding it an empty ap_config_auto.h will not do.

It might build at least and seem to work but wouldn't be correct.
Yann? :)


mod_ssl :
ssl_engine_io.obj : error LNK2019: unresolved external symbol 
_ap_filter_adopt_brigade referenced in function _char_buffer_insert


AFAIK all ap_* functions are in libhttpd, maybe we're not 
compiling/linking a new file. It looks to be in util_filters.c and that 
shows as being compiled/linked to libhttpd. ???Huh???


Looks like all the errors are related to changes in/after 2018. In 2018 
I build it without errors.


Did not build all yet and only Win32 VS16, so maybe more to come.
Let's get it building on one version first, worry about any nuances in 
the various VC versions second.



Gregg

Re: [VOTE] Release httpd-2.4.43

[Gregg Smith]

On 3/26/2020 7:50 AM, Daniel Ruggeri wrote:

Hi, all;
    Please find below the proposed release tarball and signatures:
https://dist.apache.org/repos/dist/dev/httpd/

I would like to call a VOTE over the next few days to release this
candidate tarball as 2.4.43:
[X] +1: It's not just good, it's good enough!
[ ] +0: Let's have a talk.
[ ] -1: There's trouble in paradise. Here's what's wrong.


+1 Windows building with the .mak files.
Thanks Daniel for RMing

Re: [VOTE] Release httpd-2.4.42

[Gregg Smith]

On 3/23/2020 8:18 AM, Daniel Ruggeri wrote:

Hi, all;
    Per the issues surfaced/fixed, I'll go ahead and declare this release
as dead-on-the vine. I'll target another T later this week, hopefully
after the discussion around OpenSSL versioning plays out.

    How about Thursday?



+1

Re: [VOTE] Release httpd-2.4.40

[Gregg Smith]

On 8/3/2019 6:51 AM, Daniel Ruggeri wrote:

Hi, all;
    Please find below the proposed release tarball and signatures:
https://dist.apache.org/repos/dist/dev/httpd/


[X] +1: It's good enough!

VC14 & 15 x86 & x64 w/ makefiles

Opps, looks like the APLOGNO's didn't get filled in. I'm still ok with 
releasing .40 w/o them.


mod_md.c(386): warning C4003: not enough actual parameters for macro 
'APLOGNO'
mod_md.c(391): warning C4003: not enough actual parameters for macro 
'APLOGNO'
mod_md.c(601): warning C4003: not enough actual parameters for macro 
'APLOGNO'
mod_md.c(608): warning C4003: not enough actual parameters for macro 
'APLOGNO'
mod_md.c(659): warning C4003: not enough actual parameters for macro 
'APLOGNO'
mod_md.c(702): warning C4003: not enough actual parameters for macro 
'APLOGNO'
mod_md.c(912): warning C4003: not enough actual parameters for macro 
'APLOGNO'

Re: svn commit: r1855519 - in /httpd/httpd/trunk/modules/http2: NWGNUmod_http2 mod_http2.dsp

[Gregg Smith]

Thanks Stefan :)

On 3/14/2019 6:39 AM, ic...@apache.org wrote:

Author: icing
Date: Thu Mar 14 13:39:21 2019
New Revision: 1855519

URL: http://svn.apache.org/viewvc?rev=1855519=rev
Log:
Uplift of relevante changes of r1855479 in branches/2.4.x, re disappearance of 
h2_ngn_shed.* sources.

Modified:
 httpd/httpd/trunk/modules/http2/NWGNUmod_http2
 httpd/httpd/trunk/modules/http2/mod_http2.dsp

Modified: httpd/httpd/trunk/modules/http2/NWGNUmod_http2
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/NWGNUmod_http2?rev=1855519=1855518=1855519=diff
==
--- httpd/httpd/trunk/modules/http2/NWGNUmod_http2 (original)
+++ httpd/httpd/trunk/modules/http2/NWGNUmod_http2 Thu Mar 14 13:39:21 2019
@@ -195,7 +195,6 @@ FILES_nlm_objs = \
$(OBJDIR)/h2_from_h1.o \
$(OBJDIR)/h2_h2.o \
$(OBJDIR)/h2_mplx.o \
-   $(OBJDIR)/h2_ngn_shed.o \
$(OBJDIR)/h2_push.o \
$(OBJDIR)/h2_request.o \
$(OBJDIR)/h2_headers.o \

Modified: httpd/httpd/trunk/modules/http2/mod_http2.dsp
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/mod_http2.dsp?rev=1855519=1855518=1855519=diff
==
--- httpd/httpd/trunk/modules/http2/mod_http2.dsp (original)
+++ httpd/httpd/trunk/modules/http2/mod_http2.dsp Thu Mar 14 13:39:21 2019
@@ -145,10 +145,6 @@ SOURCE=./h2_mplx.c
  # End Source File
  # Begin Source File
  
-SOURCE=./h2_ngn_shed.c

-# End Source File
-# Begin Source File
-
  SOURCE=./h2_push.c
  # End Source File
  # Begin Source File

Regression?

[Gregg Smith]

When setting a header it used to set the header case-sensitive as 
configured. Now with 2.4.38 it sets in all lower case. Regression?


Header always set X-Xss-Protection "1; mode=block"
Result;
2.4.37: X-Xss-Protection: 1; mode=block
2.4.38: x-xss-protection: 1; mode=block

If I'm reading the RFC correctly, sensitivity doesn't matter when 
parsing the header but the 2.4 docs show it outputting as configured as 
2.4 has been prior to .38.


Cheers

G

Re: Apache Win crashes with mod_md with no Applink sim

[Gregg Smith]

I objected earlier but am reversing my objection after looking through 
applink.c and the explanation of what it does below. Worse case there's 
a very small bit of unused code in httpd.exe.


Steffen tried one of my binaries and told me off-list the results so it 
seems it is needed, even when httpd & openssl come from the very same vc 
compiler. I use wilcard certs so cannot use mod_md to test the results 
myself.



On 10/19/2018 7:29 AM, William A Rowe Jr wrote:

On Fri, Oct 19, 2018 at 6:15 AM Steffen  wrote:


I changed the subject ( was Re: svn commit: r1748461 - in
/httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c)

William A Rowe Jr wrote: ...mod_php or other weirdness 

What do you mean by weirdness ? Google translate shows it can be a bad
word.



No slight intended; I'm speaking of loading binaries in-process which use
BIO
resource handles from libcrypto (libeay32 or whatever it was called) where
the
binaries arrive from different VC compilers or are built using different
memory
models (/MD vs /MT).

So in the case that a user downloads perl, php, lua, etc built against
different
VC flavors by different open source projects, and loaded in-process
underneath
Apache.exe (httpd) binary, this stub is necessary. In the case that the
user is
loading these different environments and modules built with the same linkage
by the same compiler, this stub is not necessary (except as noted in some
broken flavors of openssl.)

I never talked about a mod-php, as pointed before applink is needed for

phpXapache2_4.dll.  The Microsoft PHP team asked (and still) me to use the
sim, they had some serious reports. Quote PHP team: Yeah, now it turned
out, that the SPKI functionality in PHP requires this shim to be in. The
functionality is available since PHP 5.6 and coupled with Apache could
result an unexpected process exit without the solution mentioned in the
OpenSSL FAQ compiled in.



phpXapache2_4.dll is the apache php module by another name.

"Some reports" may still correspond to the openssl 1.0.2g bug mentioned
in the thread. Or, what is likely going on is that SPKI binaries were
compiled
against OpenSSL using a different version of the compiler.



An other example:
mod_md errors when no applink sim, in the past AL has also reports of the
issue.
Just tested again with AH httpd-2.4.35 with  Openssl 110i, and no
surprise, is does not even start, see below. Replacing the httpd.exe from
AL with the sim  all fine. Looks like a module using ssl needs the sim.



This makes sense if the OpenSSL 1.1.0i is built with a different compiler
and memory model. If it is built with the same, this should be reported to
the openssl project as a bug. The BIO interfaces are used by mod_md,
so this is expected. This is likely the 1.0.2g bug.

In any case, the usage of apache allows for arbitrary modules to be loaded
and in the binaries scenario. It seems the stub should be added in
Apache.exe
whenever mod_ssl/mod_md/aprutil have been linked to libcrypto.

This all goes against your earlier comment to me not to add this patch to
the
Apache.exe binary for building on Windows. You are reversing your objection?

I've seen another objection which suggests that "Apache.exe isn't even
linked to OpenSSL." What's important here is that the stub does not
invoke or link to OpenSSL at all. It simply provides an array of entry
points
to the current Visual Studio C Runtime, which Apache.exe is linked to,
as a shared, exported symbol that can be found by any of the .dll code
loaded in process. >
If so, based especially on mod_md and the possibility of users loading
a flavor of the libcrypto/libssl libraries which weren't created by the same
Visual Studio + memory model as when building Apache, it seems we
should proceed with patching the Apache/httpd top level binary.

Re: [Discussion] Limit the scope of 2.4.x patches until 2.4.next is released?

[Gregg Smith]

On 10/15/2018 7:10 AM, William A Rowe Jr wrote:

Like my beg for getting us to the 2.4.35 release tag, I'd like to propose
we keep patches to branches/2.4.x/ generally within the scope of
straightening out the remaining quirks related to the OpenSSL 1.1.1 API and
library behavior changes (and similar corrections for any alternate library
implementations such as LibreSSL or BoringSSL.)

This isn't a vote per se... just an ask whether we collectively want to
defer all potentially disruptive changes for a release following 2.4.next.
We can certainly resume with that next release on an expedited basis,
within a month or few (as opposed to waiting 6 months as has been typical.)

It appears that dropping in OpenSSL 1.1.1 into a previously working httpd
built against 1.1.0 is not the "plug and play" replacement that the OpenSSL
team originally envisioned, and deliberately building any previous release
of httpd against 1.1.1 is similarly broken.

Thoughts? Other concerns?


I'm in favor of the idea.

Re: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c

[Gregg Smith]

No, sorry I am still confused on just which we're talking about here, 
support/main.c or ab.c (which I was thinking) or both? Looking over this 
thread on and off list seems to be a merge of both. So because of that;


-1 to adding to applink to support/main.c. httpd.exe isn't even linked 
to ossl.


For abs.exe specifically, this all started here:
https://www.apachelounge.com/viewtopic.php?t=7134
and continued in PR 59630.

I just tested a AH vc14 build of 2.4.20 from 4/2016 and
C:\Apache24\bin>abs https://google.com/
OPENSSL_Uplink(7FF8EB479000,08): no OPENSSL_Applink

So it was a problem at one time. Today I did a vc14 x64 builds of 
current abs with the include line for applink commented out for all 
current ossl versions and none of the three fail.


Then I did a 2.4.20 build with ossl 1.0.2p and no error. Next one with 
1.0.2p and apr/u 1.5.x (as the 4/2016 build was) and again no fail. Next 
apr/u 1.5 and ossl 1.0.2g (exact same as the 4/2016 build) and

C:\Apache24\bin>abs http://google.com/
OPENSSL_Uplink(7FF900589000,08): no OPENSSL_Applink

So Bill as you eluded to somwhere in all the tl;dr in this thread you 
are correct and openssl was the problem and it does seem fixed now.


Spending much of my day on this I've found applink.c began in 0.9.8. I 
think it's always been in the ms folder and just copied to 
include(inc32)/openssl during the building process.


So knowing all this I'm now +1 on removing the applink include in ab.c.

Cheers


On 10/13/2018 11:22 AM, William A Rowe Jr wrote:

On Sat, Oct 13, 2018 at 12:00 PM Gregg Smith  wrote:


On 10/13/2018 8:32 AM, William A Rowe Jr wrote:

Sorry, I don't understand.

Gregg, can you shed some insight here? For both, applink.c is helpful if
the OpenSSL .dll files are created with a different VC compiler than
abs.exe was compiled with.


Not true, OSSL 1.0.2 I know from experience if applink.c is not included
it will still err even if both ab.c & OSSL are compiled with the same VC
version (14 & 15). I never tested 1.1.0.



I can assure you that was not true, having built against 0.9.7, .8, 1.0.0,
etc etc etc. What can break is that if you build openssl in a different
model
(the whole /MD, /MT etc) than abs.c, then yes, they could be disjointed.

Can you find me any pointers to the claim that I could investigate further?


.exe, it cannot be found from a .dll or Apache .so loadable.module.

Otherwise, I understand this to be a noop.


No, it just got moved to the ms folder is all that happened at 1.1.0 and
is still there in 1.1.1.



No, I'm certain that's incorrect. It was always in ms/ in the source bundle
and was previously installed into include/openssl/ on applicable platforms.
The fact that it isn't in the resulting installed -devel tree suggests it
is no
longer recommended, or that the openssl maintainers got the refactoring
of their build schema wrong.



I'm -1 on this till at least the majority of OSSL versions do not
include applink.c.



I read this as logical converse, you are +1 to patch main.c to include it?

This suggests we need to re-raise the issue at the openssl project or
declare 1.1.1 incompatible without the workaround of finding the library
source bundle, or manually installing applink.c where it used to be.

Re: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c

[Gregg Smith]

On 10/13/2018 8:32 AM, William A Rowe Jr wrote:

Sorry, I don't understand.

Gregg, can you shed some insight here? For both, applink.c is helpful if
the OpenSSL .dll files are created with a different VC compiler than
abs.exe was compiled with. 


Not true, OSSL 1.0.2 I know from experience if applink.c is not included 
it will still err even if both ab.c & OSSL are compiled with the same VC 
version (14 & 15). I never tested 1.1.0.



.exe, it cannot be found from a .dll or Apache .so loadable.module.
Otherwise, I understand this to be a noop.


No, it just got moved to the ms folder is all that happened at 1.1.0 and 
is still there in 1.1.1.


I'm -1 on this till at least the majority of OSSL versions do not 
include applink.c.






OpenSSL project deprecated, that is, no longer ships applink.c in
include/openssl/ install directory. LibreSSL and BoringSSL have no such
resource.

Since you indicate that patching is trivial, and building with two
different compilers isn't something an open source project should fret
about, the Apache.exe and abs.exe should behave the same way. Pick one.


On Sat, Oct 13, 2018, 04:04 Steffen  wrote:


Do not understand your writing.

abs.exe needs the applink shim, so leave it in.


Op 12 okt. 2018 om 23:54 heeft William A Rowe Jr 
het volgende geschreven:

Great, I'll proceed with changing ab.c to remove the hack, since it is
unneeded when ab.c is compiled by the same toolchain as libcrypto.dll,
isn't available in non-openssl distributions, and was deprecated in 1.1.1
again.

Anyone interested can proceed to patch both and provision applink.c when
working with OpenSSL 1.1.1, so I don't need to raise a ticket that project


On Fri, Oct 12, 2018, 16:37 Steffen  wrote:


Already for years we have in server/main.c :

#include "applink.c"


This solves errors like: no OPENSSL_Applink , see for example :
https://www.apachelounge.com/viewtopic.php?p=30986

No problem to patch.

Op 12 okt. 2018 om 22:03 heeft William A Rowe Jr 
het volgende geschreven:

... and still hanging.

Rather than ApacheLounge and some others needing to patch each time,
did we conclude that we should wire in the applink.c stub into Apache.exe
as shipped by httpd project?

(I've never mixed binaries of different MSVC environments, so myself,
I don't care, but it seems to raise issues for a subset of the community.)


On Mon, Sep 17, 2018 at 7:05 PM William A Rowe Jr 
wrote:


So we kind of left this hanging...

On Wed, Jun 15, 2016 at 2:35 PM Gregg Smith  wrote:


On 6/15/2016 9:20 AM, William A Rowe Jr wrote:

In building httpd.exe, some users don't build and install openssl. It

isn't

going
to be possible to simply #include  without some
conditional
test. OpenSSL itself is partly the culprit, for not having an
APPLINK_REQUIRED
style macro conditional. But we can work around this in the cmake

tests.




This is why the patch creator put this inside a HAVE_OPENSSL block so
ab.exe did not get this added. abs (at least on the dsp et. al.) is not
built unless there is OpenSSL present.


I'll look at making this a standard bit of the httpd 2.4 build. We can
likely
add a user-toggled flag to the os/win32/os.h?


Seems to me this is not needed .



So, is the win32 community in favor of using HAVE_OPENSSL to include
applink.c in the scope of main.c (as revised in the current ab.c sources,
to avoid this on libressl?)

There is a presumption that the crt used by libhttpd the same as libapr,
but I think this is a reasonable connection.

The entire logic to main.c should be as simple as...

#if defined(HAVE_OPENSSL) && defined(_MSC_VER) &&
!defined(LIBRESSL_VERSION_NUMBER)
/* The following logic ensures we correctly glue FILE* within one CRT
used
  * by the OpenSSL library build to another CRT used by the ab.exe build.
  * This became especially problematic with Visual Studio 2015.
  */
#include 
#endif

By inserting the structure in httpd.exe, that structure can be found by
the openssl library, which is not true of including this in a loadable
library such as libhttpd.dll or libaprutil-1.dll.

Re: NOTICE: Intent to T 2.4.36

[Gregg Smith]

FWIW, I've been running 2.4.36-dev at revision 1841586 for 19 days 35 
minutes as of this writing and I've seen no problems up to this point. 
Granted I only get a few thousand hits a day and not millions but so far 
so good. Haven't had many tls/1.3 but I would assume that's to be 
expected for another week or two until Chrome 70 and Firefox 63 come out.


Now off to build .36

On 10/10/2018 1:29 PM, William A Rowe Jr wrote:

On Wed, Oct 10, 2018, 14:53 Mark Blackman  wrote:



Does the TLSv1.3 support need to be production ready?

TLSv1.3 is presumably an opt-in feature and as long as it doesn’t endanger
existing behaviours, I would have assumed it’s relatively safe to release
with caveats in the docs.
Of course, once there’s more take-up of TLSv1.3, then the test suite needs
to be useful. Getting real-world feedback about something completely new
that doesn’t endanger existing behaviours outside of TLSv1.3 is probably
worthwhile.



Were it so easy...

It turns out httpd through 2.4.35 remain incompatible with changes to
openssl 1.1.1. This was disappointing from this project's perspective, the
issues are tracked on openssl project GitHub tickets.

If everything is good about this candidate, it should build and run against
1.1.0, or 1.1.1, whether or not TLS 1.3 is enabled or avoided.

Ben Laurie last decade tried to address this with mod_tls, but mod_ssl
remains deeply tied to the internal behavior of libssl and libcrypto, to a
degree that it is effectively impossible to drop in 1.1.1 due to mechanical
changes in the protocol.

Dropping httpd 2.4.any into openssl 1.1.1 is a mess that several committers
have applied a great deal of attention to. We've undergone the same
problems with 1.1.0, 1.0.1, 1.0.0 and 0.9.8, so this didn't come as a
surprise.

Re: [VOTE] Release httpd-2.4.35

[Gregg Smith]

On 9/17/2018 5:56 PM, Daniel Ruggeri wrote:

Hi, all;
    Please find below the proposed release tarball and signatures:
https://dist.apache.org/repos/dist/dev/httpd/

I would like to call a VOTE over the next few days to release this
candidate tarball as 2.4.35:
[ ] +1: It's not just good, it's good enough!
[ ] +0: Let's have a talk.
[ ] -1: There's trouble in paradise. Here's what's wrong.



+1 on Windows w/ apr/1.6.5, apu/1.6.1

vc11 32 & 64 bit w/ OpenSSL 1.0.2p
vc14 32 & 64 bit w/ OpenSSL 1.0.2p & 1.1.0i

Thanks for RMing Daniel

Re: 2.4.35 in Sept?

[Gregg Smith]

On 9/12/2018 1:47 PM, Jim Jagielski wrote:


What improvements do you have to suggest to improve upon this? Do you recommend a longer vote time? 
Do you recommend beta and/or release-candidates? Do you recommend that the 1st born of all voters 
be held in a camp until the release has "proven" itself to be up to your satisfaction 
ensuring that said voters have "skin in the game"?


IMO a couple extra days wouldn't hurt unless its fixing a 0day.

Re: svn commit: r1832716 - /httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy.mak

[Gregg Smith]

+1 for cmake, looks like a few short lines to add but mak/dsp, it would 
just be simpler to copy /s .\modules\*.h .\include in a prebuild step of 
libhttpd and call it good. Otherwise with 111 modules in 2.4 that's 222 
files that would need to be modified and would be overkill for some if 
not many.




On 6/2/2018 10:11 AM, William A Rowe Jr wrote:

Then let's put every modules/* directory /I into the list now across all
.mak/.dsp and cmakelists, just as the Unix build does? Then this should not
come up again until a new modules/Foo tree arrives?

WDYT?

On Sat, Jun 2, 2018, 12:01 Gregg Smith  wrote:


Well, assuming what your thinking of with OpenSSL is applink.c, that
challenge will be gone when 1.0.2 goes EOL. Libressl doesn't have
applink.c, yet, and carries with it its own challenges.

Aside from physically moving all headers to include/ in svn I don't see
this problem not popping up again sometime down the road unless you
happen to have a crystal ball.



On 6/1/2018 10:00 PM, William A Rowe Jr wrote:

Seems like another way to break the cmake build, this time, transitive
of needing modules/httpd2 from modules/proxy (still, borked).

Should we keep doing this, or move all of the includes into include/,
or create some openssl include/ symlink monstrosity, or, do we even
have a desire to fix this recurring issue?

Asking for a (group of several thousand) friend(s)...

On Fri, Jun 1, 2018 at 1:57 PM,  wrote:


Author: gsmith
Date: Fri Jun  1 18:57:21 2018
New Revision: 1832716

URL: http://svn.apache.org/viewvc?rev=1832716=rev
Log:
followup r1828485
needs mod_http2.h

Modified:
  httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy.mak

Modified: httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy.mak
URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/
modules/proxy/mod_proxy.mak?rev=1832716=1832715=1832716=diff

==
--- httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy.mak (original)
+++ httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy.mak Fri Jun  1
18:57:21 2018
@@ -63,7 +63,7 @@ CLEAN :
   if not exist "$(OUTDIR)/$(NULL)" mkdir "$(OUTDIR)"

   CPP=cl.exe
-CPP_PROJ=/nologo /MD /W3 /Zi /O2 /Oy- /I "../ssl" /I "../../include" /I
"../../srclib/apr/include" /I "../../srclib/apr-util/include" /I
"../generators" /D "NDEBUG" /D "WIN32" /D "_WINDOWS" /D
"PROXY_DECLARE_EXPORT" /Fo"$(INTDIR)\\" /Fd"$(INTDIR)\mod_proxy_src"

/FD /c

+CPP_PROJ=/nologo /MD /W3 /Zi /O2 /Oy- /I "../ssl" /I "../../include" /I
"../../srclib/apr/include" /I "../../srclib/apr-util/include" /I
"../generators" /I "../http2" /D "NDEBUG" /D "WIN32" /D "_WINDOWS" /D
"PROXY_DECLARE_EXPORT" /Fo"$(INTDIR)\\" /Fd"$(INTDIR)\mod_proxy_src"

/FD /c


   .c{$(INTDIR)}.obj::
  $(CPP) @<<
@@ -169,7 +169,7 @@ CLEAN :
   if not exist "$(OUTDIR)/$(NULL)" mkdir "$(OUTDIR)"

   CPP=cl.exe
-CPP_PROJ=/nologo /MDd /W3 /Zi /Od /I "../ssl" /I "../../include" /I
"../../srclib/apr/include" /I "../../srclib/apr-util/include" /I
"../generators" /D "_DEBUG" /D "WIN32" /D "_WINDOWS" /D
"PROXY_DECLARE_EXPORT" /Fo"$(INTDIR)\\" /Fd"$(INTDIR)\mod_proxy_src" /FD
/EHsc /c
+CPP_PROJ=/nologo /MDd /W3 /Zi /Od /I "../ssl" /I "../../include" /I
"../../srclib/apr/include" /I "../../srclib/apr-util/include" /I
"../generators" /I "../http2" /D "_DEBUG" /D "WIN32" /D "_WINDOWS" /D
"PROXY_DECLARE_EXPORT" /Fo"$(INTDIR)\\" /Fd"$(INTDIR)\mod_proxy_src" /FD
/EHsc /c

   .c{$(INTDIR)}.obj::
  $(CPP) @<<

Re: svn commit: r1832198 - /httpd/httpd/trunk/support/win32/ApacheMonitor.c

[Gregg Smith]

Hi Christophe,

This compiles and ApacheMonitor works.
Tested on VC14 & 11.

Cheers,
Gregg

On 5/24/2018 1:36 PM, jaillet...@apache.org wrote:

Author: jailletc36
Date: Thu May 24 20:36:26 2018
New Revision: 1832198

URL: http://svn.apache.org/viewvc?rev=1832198=rev
Log:
Success of 'SHGetMalloc()' should be tested with the SUCCEEDED macro.

/!\   This commit is _NOT COMPILE TESTED_. (I don't have a windows build 
environment available)
  
See PR 60086.


Modified:
 httpd/httpd/trunk/support/win32/ApacheMonitor.c

Modified: httpd/httpd/trunk/support/win32/ApacheMonitor.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/support/win32/ApacheMonitor.c?rev=1832198=1832197=1832198=diff
==
--- httpd/httpd/trunk/support/win32/ApacheMonitor.c (original)
+++ httpd/httpd/trunk/support/win32/ApacheMonitor.c Thu May 24 20:36:26 2018
@@ -912,7 +912,7 @@ LRESULT CALLBACK ConnectDlgProc(HWND hDl
  WM_SETTEXT,
  (WPARAM) NULL, (LPARAM) szCmp);
  }
-if (SHGetMalloc()) {
+if (SUCCEEDED(SHGetMalloc())) {
  pMalloc->lpVtbl->Free(pMalloc, il);
  pMalloc->lpVtbl->Release(pMalloc);
  }

Re: TLSv1.3

[Gregg Smith]

Fashionably late to the party but I've built it on Windows and it works 
for me on FF Nightly. Thanks Stefan for getting tls1.3 in and working.


Cheers

On 4/4/2018 4:24 AM, Stefan Eissing wrote:

Thanks for the tip. Unfortunately, my FF 58.0.2 and 59.0.2 still keeps doing 
TLSv1.2
while the Nightly goes TLSv1.3. Perhaps a matter of the previous draft still 
used
in the releases FF.

Just FYI.


Am 03.04.2018 um 17:09 schrieb Mario Brandt :

Hi Stefan,

On 3 April 2018 at 14:58, Stefan Eissing  wrote:

Chrome 65.0.3325.181 and FF 58.0.2 both do not on my MacOS desktop.


With FF open the about:config page

Find
security.tls.version.max

set the value from 3 to 4

Cheers
Mario

Re: mod_md : not possible to use Lets-Encrypt-Win-Simple

[Gregg Smith]

My read on the original post:

First we have stated that "For mod_ssl to work in the vote release, 
mod_md must also be included..."


That is what I honed in on. Apache will not start if there's a module 
specific directive without that module being loaded. Since the OP states 
that *mod_ssl* will not work without without mod_md included, there must 
be some mod_md directives not contained inside  laying around 
in the OP's config. I believe this is the first of two parts.


Now, Apache serving a 404 on /.well-known/acme-challenge/test.txt when 
mod_md is loaded I think is because mod_md stores this stuff under 
MDStoreDir where the acme client puts it elsewhere IIRC. So this 
behavior I see as by design since mod_md intercepts the requests coming 
from the acme server obviously to serve what is stored under MDStoreDir.


My guess anyway.


On 3/18/2018 12:07 PM, Eric Covener wrote:

On Sun, Mar 18, 2018 at 2:25 PM, Steffen  wrote:


It is indeed a limitation for an "old" account, and when LE enables TLS
again (not sure it does already in ACMEv2 protocol)


When did this become about TLS-SNI challenges and how does that tie
into the external ACME client?

Can you connect the dots for me or is this unrelated?


In my test mod_md says;

mod_md.c(1317): [client 2001:980:a510:1:c5e7:56f7:9d:ab36:65315] Challenge
for www.apachelounge.com (/.well-known/acme-challenge/test.txt)


For me case closed., sorry for the clutter.


Does this confirm something beyond "mod_md works"?


When it is not  appreciated that I share it with dev, say it please.


My own 2 cents: It would be helpful and take much less of a toll on
this volunteers time/patience/morale if this kind of feedback were
refined before being brought forward.

For example, here are hypothetical concise requirements / complaints
that someone could meaningfully address without having to pull teeth:

mod_md could do something specifically different with TLS-SNI
challenges for old users
mod_md pre-empts HTTP challenges for domains that are not mod_md managed.
mod_md can't decline/defer to an Alias for /.well-known if it has no
stored challenge

But instead we have several paragraphs about votes and releases and
mod_ssl depending on mod_md and two different clients and a request to
test "it" on Linux.

Re: [VOTE] Release httpd-2.4.32

[Gregg Smith]

On 3/9/2018 6:49 PM, Daniel Ruggeri wrote:

Hi, all;

Please find below the proposed release tarball and signatures:

https://dist.apache.org/repos/dist/dev/httpd/

  


I would like to call a VOTE over the next few days to release this candidate
tarball as 2.4.32:


[+1]: So far, so good.

SVN export tag
Win 10 vc14 32 & 64 bit
Latest APRs
OpenSSL 1.0.2n, 1.1.0g, LibreSSL 2.6.4
Latest other module dependencies
ab works!

Re: Current branche 2.4.30-dev issues

[Gregg Smith]

Ok, thanks for the clarification.

Cheers,

Gregg

On 2/25/2018 3:30 PM, William A Rowe Jr wrote:

No,

Community process. I am going to beg to restore sanity for all our
developers, not relying on any one person, and we are going to strive at a
community decision before 2.next GA, whether my suggestions carry, or not.

One of those suggestions is that win32 do nothing that the unix build
schema refused to. For 18 years we faithfully delivered a LICENSE and later
a NOTICE to the build result tree.

I've raised this repeatedly and the vast majority of the PMC does not care.
Until unix builds bother, it is time to drop this maintenance headache of
depositing the Apache License and NOTICE, nevermind appending third party
artifacts in the win32 schema.

On the topic of splitting the many-other-ways to build win32, I'm not only
supportive of your efforts to maintain this, but am willing to participate
now that I'm in sync again with modern MSVC/Studio. I'll share pointers
once my testing is complete of baby+bathwater solution to all the
prerequisite components. All I suggest is that it can sit in parallel and
be fixed both before and after release, instead of burning rev no's on
nearly every candidate.

Thanks for your efforts and enthusiasm Gregg, I'm not about to start
ignoring your input,

Cheers

Bill




On Feb 25, 2018 14:17, "Gregg Smith" <g...@gknw.net> wrote:

On 2/23/2018 10:24 AM, William A Rowe Jr wrote:


On Fri, Feb 23, 2018 at 12:01 PM, Steffen <i...@apachelounge.com> wrote:



Op 18 feb. 2018 om 17:57 heeft Eric Covener <cove...@gmail.com> het

volgende geschreven:

On Sun, Feb 18, 2018 at 11:53 AM, Steffen <i...@apachelounge.com> wrote:


On Sunday 18/02/2018 at 17:39, Eric Covener wrote:

-- not sure, mod_md; should curl and jansson be added to notice/license
files ?


I don't think either is contained in mod_md, so I don't think they
should be referenced in the NOTICES:

http://www.apache.org/dev/licensing-howto.html#mod-notice
```
Dependencies which are not included in the distribution MUST NOT be
added to LICENSE and NOTICE. As far as LICENSE and NOTICE are
concerned, only bundled bits matter.
```
On Win the curl and jansson dependencies are included in the binary
distribution.


We can't reflect what might be added in a third-party binary
distribution to the NOTICES file in httpd SVN. I think the obligation
is on whoever creates the binary distribution to enumerate what's in
it. That's what the ASF policy (same page) would be, at least.

Till now Makefile.win in SVN contains the text,for example see below.



!IF EXIST("srclib\nghttp2")
type << >> "$(INSTDIR)\NOTICE.txt"

This binary distribution of mod_http2.so includes nghttp2 C library
written
by Tatsuhiro Tsujikawa. For complete information, visit nghttp2's web
site
at https://nghttp2.org/
<<
-awk -f <>
"$(INSTDIR)\LICENSE.txt"
BEGIN {
 print "";
 print "For the mod_http2 component:";
 print "";
 while ( getline > 0 ) {
print $$0;
 }
 exit 0;
}
<<
!ENDIF



Are you asking if it would be appropriate to do the same thing for the
other dependencies?  If they're built the same way it would seem
reasonable.  I do not personally think it's necessary  (showstopper)
for a release. It looks like a convenience for someone who already
copied prereqs into srclib/.  Maybe others feel differently?



Bill and others, what do you think ?



I am getting to snapshot testing in about an hour here on Windows,
I'm just finishing up my review of 2.4.30 on Linux. I'll have more to
offer, then.

I think to be in line with other deps (like brotli, http2...) we should

add it to makefile.win, which copies to notice/license.



These are all legacies of having a command line build schema
for httpd-project distributed windows binaries, which handled the
vast amount of target tree preparation by presuming each of these
components exist within srcdir/. That's an extremely inflexible
mechanism that must be cleaned up in trunk.



So basically what your saying is that if I put any time into getting trunk
building again (have already done with exception of apreq & now
proxy_uwsgi), it's all for not and just a waste of my time because you're
going to toss it all out in the end. Am I understanding this correctly?




I'm unclear of your build process, whether you are using the SLN
schema of Makefile.win? Or using the GUI results and then just
using the nmake install step of Makefile.win?



InstallBin is just nmake _install, so there's no difference.
# PROP Cmd_Line "NMAKE /f makefile.win INSTDIR="\Apache24" SHORT=R
LONG=Release _install"

And since nmake _install has a dependency to nmake _build(r/d) (like
InstallBin to BuildBin), it would just builds everything again if you used
nmake install(r/d) after building with the GUI.




In any case, for those components which the Makefile.win

Re: Current branche 2.4.30-dev issues

[Gregg Smith]

On 2/23/2018 10:24 AM, William A Rowe Jr wrote:

On Fri, Feb 23, 2018 at 12:01 PM, Steffen  wrote:



Op 18 feb. 2018 om 17:57 heeft Eric Covener  het volgende 
geschreven:


On Sun, Feb 18, 2018 at 11:53 AM, Steffen  wrote:

On Sunday 18/02/2018 at 17:39, Eric Covener wrote:

-- not sure, mod_md; should curl and jansson be added to notice/license
files ?


I don't think either is contained in mod_md, so I don't think they
should be referenced in the NOTICES:

http://www.apache.org/dev/licensing-howto.html#mod-notice
```
Dependencies which are not included in the distribution MUST NOT be
added to LICENSE and NOTICE. As far as LICENSE and NOTICE are
concerned, only bundled bits matter.
```
On Win the curl and jansson dependencies are included in the binary
distribution.


We can't reflect what might be added in a third-party binary
distribution to the NOTICES file in httpd SVN. I think the obligation
is on whoever creates the binary distribution to enumerate what's in
it. That's what the ASF policy (same page) would be, at least.

Till now Makefile.win in SVN contains the text,for example see below.



!IF EXIST("srclib\nghttp2")
type << >> "$(INSTDIR)\NOTICE.txt"

This binary distribution of mod_http2.so includes nghttp2 C library written
by Tatsuhiro Tsujikawa. For complete information, visit nghttp2's web site
at https://nghttp2.org/
<<
-awk -f <> "$(INSTDIR)\LICENSE.txt"
BEGIN {
print "";
print "For the mod_http2 component:";
print "";
while ( getline > 0 ) {
print $$0;
}
exit 0;
}
<<
!ENDIF



Are you asking if it would be appropriate to do the same thing for the
other dependencies?  If they're built the same way it would seem
reasonable.  I do not personally think it's necessary  (showstopper)
for a release. It looks like a convenience for someone who already
copied prereqs into srclib/.  Maybe others feel differently?


Bill and others, what do you think ?


I am getting to snapshot testing in about an hour here on Windows,
I'm just finishing up my review of 2.4.30 on Linux. I'll have more to
offer, then.


I think to be in line with other deps (like brotli, http2...) we should add it 
to makefile.win, which copies to notice/license.


These are all legacies of having a command line build schema
for httpd-project distributed windows binaries, which handled the
vast amount of target tree preparation by presuming each of these
components exist within srcdir/. That's an extremely inflexible
mechanism that must be cleaned up in trunk.


So basically what your saying is that if I put any time into getting 
trunk building again (have already done with exception of apreq & now 
proxy_uwsgi), it's all for not and just a waste of my time because 
you're going to toss it all out in the end. Am I understanding this 
correctly?




I'm unclear of your build process, whether you are using the SLN
schema of Makefile.win? Or using the GUI results and then just
using the nmake install step of Makefile.win?


InstallBin is just nmake _install, so there's no difference.
# PROP Cmd_Line "NMAKE /f makefile.win INSTDIR="\Apache24" SHORT=R 
LONG=Release _install"


And since nmake _install has a dependency to nmake _build(r/d) (like 
InstallBin to BuildBin), it would just builds everything again if you 
used nmake install(r/d) after building with the GUI.




In any case, for those components which the Makefile.win does
physically copy into the target tree, it ought to also be appending
the NOTICE. Where it does not take responsibility to move the
third party lib, it should not extend the NOTICE. Does that seem
rational?

We (httpd source tree maintainers) should be out of the business
of handling 'make install' steps for third party packages. As a
distributor, I'm sure you and others appreciate the current
convenience, but it involves generally knowing which rev level
each third party package is at, and distributors can and will
disagree on which components and versions should be linked
into their own build of httpd for their purposes. > > I'm happy to collaborate 
on such helpful scripts and utilities but
they belong out of the /httpd/httpd/branches/rev/ tree so that they
don't interfere with the release cycle of the primary source project.

Re: svn commit: r1807709 - 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_engine_init.c modules/ssl/ssl_private.h

[Gregg Smith]

Stefan,

Yes, that and vhost.c would.


Gregg

On 1/22/2018 12:29 AM, Stefan Eissing wrote:

Gregg,

that'd mean we need an AP_DECLARE on that in http_vhost.h? Would that suffice?

Cheers, Stefan


Am 20.01.2018 um 03:50 schrieb Gregg Smith <g...@gknw.net>:

Hi Stefan,

Specific to ssl_engine_config.c, on Win32 we need to have 
ap_parse_vhost_addrs() exported from vhost.c.

Cheers,

G

On 9/8/2017 3:29 AM, ic...@apache.org wrote:

Author: icing
Date: Fri Sep  8 10:29:53 2017
New Revision: 1807709

URL: http://svn.apache.org/viewvc?rev=1807709=rev
Log:
On the trunk:

mod_ssl: Extending SSLEngine to alternatively get a list of add:port spec as 
used in VirtualHost.


Modified:
 httpd/httpd/trunk/CHANGES
 httpd/httpd/trunk/docs/manual/mod/mod_ssl.xml
 httpd/httpd/trunk/modules/ssl/mod_ssl.c
 httpd/httpd/trunk/modules/ssl/ssl_engine_config.c
 httpd/httpd/trunk/modules/ssl/ssl_engine_init.c
 httpd/httpd/trunk/modules/ssl/ssl_private.h

Modified: httpd/httpd/trunk/CHANGES
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1807709=1807708=1807709=diff
==
--- httpd/httpd/trunk/CHANGES [utf-8] (original)
+++ httpd/httpd/trunk/CHANGES [utf-8] Fri Sep  8 10:29:53 2017
@@ -1,6 +1,9 @@
   -*- coding: utf-8 -*-
  Changes with Apache 2.5.0
  +  *) mod_ssl: Adding option to set a list of addr:port specs, as used in 
VirtualHosts
+ to enable SSLEngine for all matching hosts. Updated documentation. 
[Stefan Eissing]
+
*) core: Disallow Methods' registration at runtime (.htaccess), they may be
   used only if registered at init time (httpd.conf).  [Yann Ylavic]
  
Modified: httpd/httpd/trunk/docs/manual/mod/mod_ssl.xml

URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_ssl.xml?rev=1807709=1807708=1807709=diff
==
--- httpd/httpd/trunk/docs/manual/mod/mod_ssl.xml (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_ssl.xml Fri Sep  8 10:29:53 2017
@@ -550,15 +550,15 @@ SSLSessionCacheTimeout 600
  
  SSLEngine
  SSL Engine Operation Switch
-SSLEngine on|off|optional
+SSLEngine on|off|optional|addr[:port] [addr[:port]] ...
  SSLEngine off
  server config
  virtual host

  
-This directive toggles the usage of the SSL/TLS Protocol Engine. This
-is should be used inside a VirtualHost section to enable SSL/TLS for a
  that virtual host. By default the SSL/TLS Protocol Engine is
  disabled for both the main server and all configured virtual hosts.
@@ -569,6 +569,18 @@ SSLEngine on
  #...
  /VirtualHost
  
+
+In Apache 2.4 and later, addr:port values should be used in the
+global server to enable the SSL/TLS Protocol Engine for all
+VirtualHosts
+that match one of the addresses in the list.
+Example
+
+SSLEngine *:443
+VirtualHost *:443
+#...
+/VirtualHost
+
  
  In Apache 2.1 and later, SSLEngine can be set to
  optional. This enables support for

Modified: httpd/httpd/trunk/modules/ssl/mod_ssl.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/mod_ssl.c?rev=1807709=1807708=1807709=diff
==
--- httpd/httpd/trunk/modules/ssl/mod_ssl.c (original)
+++ httpd/httpd/trunk/modules/ssl/mod_ssl.c Fri Sep  8 10:29:53 2017
@@ -91,7 +91,7 @@ static const command_rec ssl_config_cmds
  /*
   * Per-server context configuration directives
   */
-SSL_CMD_SRV(Engine, TAKE1,
+SSL_CMD_SRV(Engine, RAW_ARGS,
  "SSL switch for the protocol engine "
  "('on', 'off')")
  SSL_CMD_SRV(FIPS, FLAG,
@@ -490,6 +490,75 @@ static SSLConnRec *ssl_init_connection_c
  return sslconn;
  }
  +static int ssl_server_addr_matches(server_addr_rec *sar, apr_sockaddr_t *sa)
+{
+/* Determine if the list of server_addr_rec's matches the given socket 
address.
+ * IP Address/port may be wilcard/0 for a match to occur. */
+while (sar) {
+if (apr_sockaddr_is_wildcard(sar->host_addr)
+|| apr_sockaddr_equal(sar->host_addr, sa)) {
+if (sar->host_addr->port == sa->port
+|| sar->host_addr->port == 0
+|| sa->port == 0) {
+return 1;
+}
+}
+sar = sar->next;
+}
+return 0;
+}
+
+int ssl_server_addr_overlap(server_addr_rec *sar1, server_addr_rec *sar2)
+{
+if (sar1) {
+while (sar2) {
+if (ssl_server_addr_matches(sar1, sar2->host_addr)) {
+return 1;
+}
+sar2 = sar2->next;
+}
+}
+return 0;
+}
+
+static ssl_enabled_t ssl_srv_enabled_on(server_rec *s, apr_sockaddr_t *sa)
+{
+SSLSrvConfigRec *sc = mySrvConfig(s);
+if (sc->enabled == SSL_ENABLED_TRUE && sc->enabled_on) {
+  

Re: svn commit: r1807709 - 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_engine_init.c modules/ssl/ssl_private.h

[Gregg Smith]

Hi Stefan,

Specific to ssl_engine_config.c, on Win32 we need to have 
ap_parse_vhost_addrs() exported from vhost.c.


Cheers,

G

On 9/8/2017 3:29 AM, ic...@apache.org wrote:

Author: icing
Date: Fri Sep  8 10:29:53 2017
New Revision: 1807709

URL: http://svn.apache.org/viewvc?rev=1807709=rev
Log:
On the trunk:

mod_ssl: Extending SSLEngine to alternatively get a list of add:port spec as 
used in VirtualHost.


Modified:
 httpd/httpd/trunk/CHANGES
 httpd/httpd/trunk/docs/manual/mod/mod_ssl.xml
 httpd/httpd/trunk/modules/ssl/mod_ssl.c
 httpd/httpd/trunk/modules/ssl/ssl_engine_config.c
 httpd/httpd/trunk/modules/ssl/ssl_engine_init.c
 httpd/httpd/trunk/modules/ssl/ssl_private.h

Modified: httpd/httpd/trunk/CHANGES
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1807709=1807708=1807709=diff
==
--- httpd/httpd/trunk/CHANGES [utf-8] (original)
+++ httpd/httpd/trunk/CHANGES [utf-8] Fri Sep  8 10:29:53 2017
@@ -1,6 +1,9 @@
   -*- coding: utf-8 -*-
  Changes with Apache 2.5.0
  
+  *) mod_ssl: Adding option to set a list of addr:port specs, as used in VirtualHosts

+ to enable SSLEngine for all matching hosts. Updated documentation. 
[Stefan Eissing]
+
*) core: Disallow Methods' registration at runtime (.htaccess), they may be
   used only if registered at init time (httpd.conf).  [Yann Ylavic]
  


Modified: httpd/httpd/trunk/docs/manual/mod/mod_ssl.xml
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_ssl.xml?rev=1807709=1807708=1807709=diff
==
--- httpd/httpd/trunk/docs/manual/mod/mod_ssl.xml (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_ssl.xml Fri Sep  8 10:29:53 2017
@@ -550,15 +550,15 @@ SSLSessionCacheTimeout 600
  
  SSLEngine
  SSL Engine Operation Switch
-SSLEngine on|off|optional
+SSLEngine on|off|optional|addr[:port] [addr[:port]] ...
  SSLEngine off
  server config
  virtual host
  
  

  
-This directive toggles the usage of the SSL/TLS Protocol Engine. This
-is should be used inside a VirtualHost section to enable SSL/TLS for a
  that virtual host. By default the SSL/TLS Protocol Engine is
  disabled for both the main server and all configured virtual hosts.
@@ -569,6 +569,18 @@ SSLEngine on
  #...
  /VirtualHost
  
+
+In Apache 2.4 and later, addr:port values should be used in the
+global server to enable the SSL/TLS Protocol Engine for all
+VirtualHosts
+that match one of the addresses in the list.
+Example
+
+SSLEngine *:443
+VirtualHost *:443
+#...
+/VirtualHost
+
  
  In Apache 2.1 and later, SSLEngine can be set to
  optional. This enables support for

Modified: httpd/httpd/trunk/modules/ssl/mod_ssl.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/mod_ssl.c?rev=1807709=1807708=1807709=diff
==
--- httpd/httpd/trunk/modules/ssl/mod_ssl.c (original)
+++ httpd/httpd/trunk/modules/ssl/mod_ssl.c Fri Sep  8 10:29:53 2017
@@ -91,7 +91,7 @@ static const command_rec ssl_config_cmds
  /*
   * Per-server context configuration directives
   */
-SSL_CMD_SRV(Engine, TAKE1,
+SSL_CMD_SRV(Engine, RAW_ARGS,
  "SSL switch for the protocol engine "
  "('on', 'off')")
  SSL_CMD_SRV(FIPS, FLAG,
@@ -490,6 +490,75 @@ static SSLConnRec *ssl_init_connection_c
  return sslconn;
  }
  
+static int ssl_server_addr_matches(server_addr_rec *sar, apr_sockaddr_t *sa)

+{
+/* Determine if the list of server_addr_rec's matches the given socket 
address.
+ * IP Address/port may be wilcard/0 for a match to occur. */
+while (sar) {
+if (apr_sockaddr_is_wildcard(sar->host_addr)
+|| apr_sockaddr_equal(sar->host_addr, sa)) {
+if (sar->host_addr->port == sa->port
+|| sar->host_addr->port == 0
+|| sa->port == 0) {
+return 1;
+}
+}
+sar = sar->next;
+}
+return 0;
+}
+
+int ssl_server_addr_overlap(server_addr_rec *sar1, server_addr_rec *sar2)
+{
+if (sar1) {
+while (sar2) {
+if (ssl_server_addr_matches(sar1, sar2->host_addr)) {
+return 1;
+}
+sar2 = sar2->next;
+}
+}
+return 0;
+}
+
+static ssl_enabled_t ssl_srv_enabled_on(server_rec *s, apr_sockaddr_t *sa)
+{
+SSLSrvConfigRec *sc = mySrvConfig(s);
+if (sc->enabled == SSL_ENABLED_TRUE && sc->enabled_on) {
+if (!ssl_server_addr_matches(sc->enabled_on, sa)) {
+return SSL_ENABLED_FALSE;
+}
+}
+return sc->enabled;
+}
+
+static ssl_enabled_t ssl_conn_enabled(conn_rec *c)
+{
+if (c->master) {
+return ssl_conn_enabled(c->master);
+}
+else {
+SSLConnRec *sslconn = myConnConfig(c);

Re: Current branche 2.4.x error

[Gregg Smith]

Done.
trunk r1821195
2.4.x r1821196

On 1/15/2018 8:53 AM, Steffen wrote:

Gregg  must have a look in the .mak files maybe better he commits (as usual).

Added in libhttpd.dsp :

SOURCE=.\server\config.c
# End Source File

+# Begin Source File
+
+SOURCE=.\server\util_debug.c
+# End Source File



Op 15 jan. 2018 om 17:20 heeft Yann Ylavic  het volgende 
geschreven:

Hi Steffen,


On Sun, Jan 14, 2018 at 5:05 PM, Steffen  wrote:
Thanks Eric, it builds now.


Could you please commit your change(s) to trunk?
That way we could backport it(them) to 2.4.x and get it fixed.

Thanks,
Yann.

Re: svn commit: r1820578 - /httpd/httpd/branches/2.4.x-mod_md/os/win32/BaseAddr.ref

[Gregg Smith]

Everything in 2.4 is also in trunk with the exception of the .mak/dep 
files AFAIK. BaseAddr.ref will not merge/backport to 2.4 w/o conflict is 
all, like CHANGES.


If any module in trunk is not being built then please do share Steffen 
on which module/s is/are not being built.


Yann, your change to BaseAddr.ref is fine.


Gregg


On 1/9/2018 3:59 AM, Steffen wrote:

Mod_md looks ok in trunk, it is the rest.

I think Gregg can comment to this.




Op 9 jan. 2018 om 12:52 heeft Yann Ylavic  het volgende 
geschreven:


On Tue, Jan 9, 2018 at 12:33 PM, Steffen  wrote:
Reason not to update trunk: As pointed here before, trunk is not up
to date concerning Win build-files.


Do you mean that 2.4.x(-mod_md) is up to date but not trunk?
This shouldn't happen (no commit should land in 2.4.x without being
first committed in trunk).
Can we fix this?

Re: mod_ssl versions (for mod_md)

[Gregg Smith]

On 1/5/2018 2:25 PM, Yann Ylavic wrote:

Hi Steffen,

On Fri, Jan 5, 2018 at 10:26 PM, Steffen  wrote:


What is the one we have to test for next 2.4.30, special mod_md 1.1.8


I have just synchonized the 2.4.x-mod_md branch with 2.4.x (resolving
only a tiny conflict in a comment).
So they should be exactly the same (mod_ssl included), except for the
pure mod_md changes, thus you should use the 2.4.x-mod_md branch I
guess.

Attached is the diff between the two branches' mod_ssl (svn diff -x-p
--- httpd/httpd/branches/2.4.x-mod_md/modules/ssl/ssl_engine_init.c 
2018/01/05 15:34:15	1820314
+++ httpd/httpd/branches/2.4.x-mod_md/modules/ssl/ssl_engine_init.c 
2018/01/05 22:04:52	1820360

@@ -32,6 +32,22 @@
 #include "mpm_common.h"
 #include "mod_md.h"

+/* Use the header, once mod_md is backported. break the dependency loop 
for now. */

+#define MOD_MD_BACKPORTED   0

#define MOD_MD_BACKPORTED   1
This branch does have MOD_MD_BACKPORTED after all.

+#if MOD_MD_BACKPORTED
+#include "mod_md.h"
+#else
+APR_DECLARE_OPTIONAL_FN(int,
+md_is_managed, (struct server_rec *));
+APR_DECLARE_OPTIONAL_FN(apr_status_t,
+md_get_certificate, (struct server_rec *, 
apr_pool_t *,

+ const char **pkeyfile,
+ const char **pcertfile));
+APR_DECLARE_OPTIONAL_FN(int,
+md_is_challenge, (struct conn_rec *, const char *,
+  X509 **pcert, EVP_PKEY **pkey));
+#endif
+
 APR_IMPLEMENT_OPTIONAL_HOOK_RUN_ALL(ssl, SSL, int, init_server,
 (server_rec *s,apr_pool_t *p,int 
is_proxy,SSL_CTX *ctx),
 (s,p,is_proxy,ctx), OK, DECLINED)> 
Regards,

Yann.


Regards,

Gregg

Re: [VOTE] Release Apache httpd 2.4.29 as GA

[Gregg Smith]

Well I got it now thanks mostly to your instructions Steefen, took 
awhile but once I put the the pieces together I see what needs to be done.


On 10/20/2017 1:44 AM, Steffen wrote:


Nope, just double clicking Apache.dsw does now not create the xml 
solution.  And without xml solution  httpd does not build (httpd 
regression).


When I revert the Apache.dsw changes all fine, no headache and is not 
complicated at all here.



I do not care where expat is located.

And cmake is not my way to go, still not getting a complete build 
(please  do not start the discussion cmake vs .dsp again, the cmake 
quircks/limitations  are pointed out several times).


Ps.
For my personal use, when apr-util 1.6.1 is GA I revert also there the 
expat related changes, till all is settled.






On Friday 20/10/2017 at 02:49, William A Rowe Jr  wrote:

On Thu, Oct 19, 2017 at 4:15 PM, Steffen  wrote:


I said before: In Apache.dsw is now  project xml  removed, it is not 
building out of the box with current released apr-util. With coming 
apr-util 1.6.1 it should be possible to build.


With the expat/xml changes in apr-util and httpd, it is now a hard 
job for most win users to build.


Going with the “old” Apache.dsw and current apr-util, all looks fine. 
The 2.4.28 regression mod_proxy loadfactor issue is solved and it 
works now again.


Formal it is hard to say to go or not, so a +0.


By building out of the box, you mean building expat for you? That
behavior is by design, of course.

Reading your details on the other list, you are having problems with
the envvar, and attempted to build expat into its old location (and
further, are simply going to stay with the old xml.dsp logic not
provided by the expat project?)

Are you launching devenv with the /useenv flag with desired variables
set? It only promises to bring in your environment INCLUDE, LIB,
LIBPATH and PATH variables, so I'm not sure if it is a 100% solution.

It seems you and Gregg want to accomplish three different things,
Gregg thinks the obvious place for expat is under srclib/expat
(actually it unpacks as libexpat, shrug), you want to continue to
expand expat underneath srclib/apr-util/xml/, and I don't care, since
I build it entirely out-of-tree under the unpacked directory name,
configure and install into the target tree, and then set LIB and
INCLUDE as already documented for PCRE.

I'd like to support as many realistic use cases as possible while we
continue to clean up the segregation of httpd from apr[-util|-iconv],
so searching from the apr-util/ tree either xml/expat/lib or
../expat/lib seems reasonable to me.

Doesn't seem this is a regression, unless something that was working
quit working, and the build didn't work before with expat 2.2.4, so
that isn't in question.

Looking for good solutions here to help users accomplish builds in a
variety of ways without overcomplicating our project's long term
maintenance (extra headaches during httpd-2.4 are expected, of
course.) This basic logic should be working, for example;
https://wiki.apache.org/httpd/WindowsTrunkCompilation

Re: [VOTE] Release Apache httpd 2.4.29 as GA

[Gregg Smith]

On 10/19/2017 5:49 PM, William A Rowe Jr wrote:

On Thu, Oct 19, 2017 at 4:15 PM, Steffen  wrote:

I said before: In Apache.dsw is now  project xml  removed, it is not building 
out of the box with current released apr-util. With coming apr-util 1.6.1 it 
should be possible to build.

With the expat/xml changes in apr-util and httpd, it is now a hard job for most 
win users to build.

Going with the “old” Apache.dsw and current apr-util, all looks fine. The 
2.4.28 regression mod_proxy loadfactor issue is solved and it works now again.

Formal it is hard to say to go or not, so a +0.


By building out of the box, you mean building expat for you? That
behavior is by design, of course.

Reading your details on the other list, you are having problems with
the envvar, and attempted to build expat into its old location (and
further, are simply going to stay with the old xml.dsp logic not
provided by the expat project?)

Are you launching devenv with the /useenv flag with desired variables
set? It only promises to bring in your environment INCLUDE, LIB,
LIBPATH and PATH variables, so I'm not sure if it is a 100% solution.



set XML_PARSER=libexpat
devenv /useenv Apache.dsw

That should fix that. I read in that building in it's old location was 
the only way plus a little tinkering the project to give it a libpath to 
the lib. But then, that's what has to be done regardless of where expat 
is. But your not getting this, there's no libpath: in the dsp/mak. That 
missing and an include that still points to xml/expat/lib leads us to 
believe we have to put it there, Though I knew better.


Now I can't speak for Steffen but the "putting expat in xml/ should have 
clued you in to exactly what I said (on this very thing) at least enough 
to ask for clarification with an open mind.


The only guidance we have is to look at the makefiles. The only thing to 
latch onto to give us the slightest clue what you were thinking was the 
one include, which remains /I "xml/expat/lib" ergo never removed or 
modified to point someplace, anyplace where we are supposed to have it. 
In httpd's case maybe srclib/*expat, I really don't care where, but we 
need to know where.



It seems you and Gregg want to accomplish three different things,
Gregg thinks the obvious place for expat is under srclib/expat
(actually it unpacks as libexpat, shrug), you want to continue to
expand expat underneath srclib/apr-util/xml/, and I don't care, since
I build it entirely out-of-tree under the unpacked directory name,
configure and install into the target tree, and then set LIB and
INCLUDE as already documented for PCRE.



I don't read that into it. Again I don't care where it has to be so long 
as we pick a place and stick to it and have a correct /I and /libpath:.



I'd like to support as many realistic use cases as possible while we
continue to clean up the segregation of httpd from apr[-util|-iconv],
so searching from the apr-util/ tree either xml/expat/lib or
../expat/lib seems reasonable to me.


Realistic to whom ... you? One man's patriot is another man's traitor.

This isn't a "use case" however, this is a "getting this all to build 
case" period. We don't like upheaval but we do adapt, just we have no 
guidance here to adapt to.




Doesn't seem this is a regression, unless something that was working
quit working, and the build didn't work before with expat 2.2.4, so
that isn't in question.


Actually, 2.2.3 broke the build which I fixed. 2.2.4 just added a c99 
factor for the older c89 versions of VC. I wouldn't call this a 
regression here, it's broken at the apr level.




Looking for good solutions here to help users accomplish builds in a
variety of ways without overcomplicating our project's long term
maintenance (extra headaches during httpd-2.4 are expected, of
course.) This basic logic should be working, for example;
https://wiki.apache.org/httpd/WindowsTrunkCompilation



There we go, last time I built APR2 I just put expat in a folder named 
"expat" just outside apr's and it worked, because all the include and 
libpath pointers were there to help me figure it out.

Re: [VOTE] Release Apache httpd 2.4.28 as GA

[Gregg Smith]

+1 to doing a 2.4.29 next week with these issues fixed.

On 9/27/2017 9:21 PM, William A Rowe Jr wrote:

The assert() has me concerned, and Steffen's report is problematic. He has
a vote but hasn't cast it. At this moment I'm -0 and would spin a 2.4.29
next week to address these issues, unless you decide to respin before this
release, yourself.

Nothing I've changed today altered the httpd tarball significantly.
Studying Steffen's report next, along with some apparently missing glue for
brotli.

My solution is going to be radical, shove every last d*mned modules/foo
into the /I path includes list so this can't happen again during 2.4, and
hopefully not until 20 year old build logic is discarded. One less thing to
worry about or pre-review when RM's loudly announce an upcoming tag.




On Sep 25, 2017 07:13, "Jim Jagielski"  wrote:


The pre-release test tarballs for Apache httpd
version 2.4.28 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.28 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!

Re: [VOTE] Release Apache httpd 2.4.27 as GA

[Gregg Smith]

On Jul 6, 2017, at 1:45 PM, Jim Jagielski  wrote:

The pre-release test tarballs for Apache httpd
version 2.4.27 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.27 GA.


+1 Windows 7/8.1/2012R2, x86 & 64 VC9, 11, 14, VC15 x64
APR 1.6.2 APU 1.6.0
OpenSSL 1.0.2l VC9, 11 & 14
OpenSSL 1.1.0f (VC14 & 15)
brotli 0.6.0, Expat 2.2.1

Re: [VOTE] Release httpd-2.2.34

[Gregg Smith]

On 7/6/2017 12:33 PM, William A Rowe Jr wrote:

Your votes on two decisions, please?


[+1] Release 2.2.34 as legacy GA
[+1] Retire the 2.2.x branch from any further maintenance.

Re: svn commit: r1799731 - in /httpd/httpd/trunk: CHANGES server/request.c

[Gregg Smith]

Sorry Bill for the off-list mail now twice but either the list or 
thunderbird's behavior with this list has changed. I'll assume the 
former since I do not see the reply-to dev@ header anymore.


On 6/24/2017 10:02 AM, William A Rowe Jr wrote:

On Sat, Jun 24, 2017 at 12:49 AM,   wrote:

Author: gsmith
Date: Sat Jun 24 05:49:45 2017
New Revision: 1799731

URL: http://svn.apache.org/viewvc?rev=1799731=rev
Log:
Send a 404 response like other OSs do instead of 403 on Windows when
a path segment or file requested uses a reserved word so Windows
cannot be fingerprinted. PR55887


How does this solve fingerprinting?


Simple Bill, does this 403?
http://httpd.apache.org/lpt1/
No.

Does it on Windows?
https://is.kaput.gq/lpt1
Yes

Does this?
http://httpd.apache.org/foo/bar/lpt1/test/
No.

This?
https://is.kaput.gq/foo/bar/lpt1/test/
Yes

Granted /foo/bar has to exist or it will never make it that far and 404's.

While my server header may only say Apache, not hard to figure out what 
it's running on due to the different behavior.



It's always going to 403 on Windows

https://is.kaput.gq/lpt1.php

Which is what lead me to 00038 in the first place.



This patch was ill-conceived... -1 as explained below;


+#ifdef _WIN32
+/* Windows has a number of reserved words that cannot be used
+ * as a file or directory name so thisinfo.filetype will
+ * always be != APR_DIR. Don't allow us be fingerprinted with
+ * a 403 and instead send a 404 like other OSs would. PR55887
+ */
+preg = ap_pregcomp(r->pool,
+  
"/(aux|con|com[1-9]|lpt[1-9]|nul|prn)"
+  "($|/|.)", 
AP_REG_EXTENDED | AP_REG_ICASE);
+if (ap_regexec(preg, r->uri, 0, NULL, 0) == 0)
+return r->status = HTTP_NOT_FOUND;
+#endif


You should be aware that this code path can be hit a number of times
per request, often hundreds for an autoindex listing, etc. You should
see a notable rise in cpu.


I am after sitting on the beach thinking about what Yann meant in his reply.



As suggested this could be a compile-once and recycle pattern.

But why a regex against the URI?!? That's horrible, you are reparsing
all those leading bytes we already parsed. Part of the URI may have
been alias-mapped away from one resource name to another (or in
the htaccess case, mapped into a badly named path.) r->filename
is the cumulative name of the *FILE* we are inspecting, not *URI*.


Mainly because I had a problem with r->filename and with r->uri I 
didn't. However, I know the problem I had was not with r->filename but I 
forgot to run back to it.



Worse still, because seg_name is the actual path component we are
now looking at, e.g. from /path/to/lpt1/foo - if we are at the third elt
that string becomes the normalized form of lpt1. There was no reason
to be reinspecting the earlier path elts throughout the segment walk!

But this could all be identified by the APR_CHR ->filetype, no? Sure
beats an unnecessarily long string pattern match.


Mainly because I did not know about it and I can't say whether or not 
I'd have known what "a character device" meant though I hope I would have.




While we are at it, why even forking WIN32? If you want to prevent
APR_CHR files on Windows (or netware or os2 or...) from being
identified, why wouldn't you simply change the behavior across all
architectures with a new test case ahead of the != APR_DIR check...

 else if (thisinfo.filetype == APR_CHR) {
 ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(00038)
   "Forbidden: %s points to a char stream path",
   r->filename);
 return r->status = HTTP_NOT_FOUND;
 }


Uh yes, but as shown up front the 404 is what we'd get on Unix and 
forcing it 404 is what I was doing while improperly.



else if (thisinfo.filetype != APR_DIR) {
 ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(00038)
   "Forbidden: %s doesn't point to "
   "a file or directory",
   r->filename);
 return r->status = HTTP_FORBIDDEN;
 }

As I asked upfront, why is it believed that this solves the win32
issue? 


Because I tested and got a 404 instead of a 403 with the numerous 
possibilities I tried.


It's trivial to check for case folding and that folding will

occur in a manner unique to the Windows implementation of the
NTFS filesystem. You would need to modify the following code
to force case mismatches to a 404 result to try to convince anyone
that the server is running on unix, non-samba;

 if ((thisinfo.valid & APR_FINFO_NAME)
 && strcmp(seg_name, thisinfo.name)) {
 /* TODO: 

Re: [VOTE] Release Apache httpd 2.4.26 as GA

[Gregg Smith]

On 6/13/2017 10:33 AM, Jim Jagielski wrote:

The pre-release test tarballs for Apache httpd
version 2.4.26 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.26 GA.

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


+1 on Windows

Re: The drive for 2.4.26

[Gregg Smith]

Yes it did, thanks for following up.

On 5/22/2017 9:23 AM, Jacob Champion wrote:

On 04/20/2017 01:06 PM, Gregg Smith wrote:

This is ApacheBench, Version 2.3 <$Revision: 1750960 $>
Same result with trunk, it just hangs.

Glad it's not just Windows!


Gregg, did Rainer's patch work for you on Windows? Looks like it hasn't 
been pushed into trunk yet, so I'll apply it today and will be proposing 
for backport.


--Jacob

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[Gregg Smith]

On 4/30/2017 5:36 AM, Jan Ehrhardt wrote:


The problem with CMake is that it does not build all things, that AL and
AH put in their distributions. CMake will build Apr 1.6 and Apr-util
1.6, including apr_crypto_openssl-1.dll (1.0.2 or 1.1.0) in one go.



Yes Jan I realize this but "recommend" does not mean "you must."

The http project has recommended people use 2.4.x since it came out. We 
did not force people from using 2.2.x did we?

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[Gregg Smith]

On 4/29/2017 5:19 PM, Gregg Smith wrote:


Bill, viewing the complete thread your reasoning here should have
precluded this discussion years ago when pcre went to cmake, so at or
before 2.4.0. After all, it's the only way to build pcre which is a hard
requirement, not soft like brotli.



I guess I didn't see it all. I see now where your reasoning is as far as 
doing it now and not before.


I see no majority as 3 do, 3 do not (if I include expat). This is 
assuming nghttp2 fixed the cmake problem I had on windows. I would think 
so as a long time and many versions have come since then.


I'm still against removal/shorting legacy yet not against recommending 
cmake.

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[Gregg Smith]

On 4/28/2017 9:35 AM, Jan Ehrhardt wrote:

William A Rowe Jr in gmane.comp.apache.devel (Fri, 28 Apr 2017 10:30:03
-0500):

You might have missed my thought here... suggesting that the CMake
not-so-experimental build become recommended for users who want to
build all the modules in one go including the new mod_brotli.


People like Steffen, Gregg and me disagree with you on making CMake the
only way for building Apache and all the modules in one go.


Maybe we have an English->Dutch translation error?

I have no problem with "recommending" folks use cmake, none at all. I 
find it to be a pain in the backside but that's just me. Others may 
share this but I will not stand in the way of simply "recommending" it. 
I'm actually for it so there are less folks new to building httpd having 
problems because of all the quirks the different VC versions have.


I do however have a problem with any thought or discussion of removing 
or shorting modules in the legacy build up until such time as it really 
is impossible to build with it or simply goes stale because of lack of 
will to keep it up to date which as of now has not yet happened.


Bill, viewing the complete thread your reasoning here should have 
precluded this discussion years ago when pcre went to cmake, so at or 
before 2.4.0. After all, it's the only way to build pcre which is a hard 
requirement, not soft like brotli.





It sounds like you attempted to export mod_brotli.dsp to a vcproj all
on it's own which has never been possible.


It is perfectly possible. That is how I added mod_fcgid and now
mod_brotli to my existing Apache 2.4.25 sln. Convert to vcproj (VC9) or
vcxproj (VC11/VC14), add the x64 configuration, add the vc(x)proj as an
existing project to Apache.sln. I am doing the same thing when mod_http2
changes the headers or sources.

For 2.4.next I will convert Apache.dsw once again and add mod_fcgid
afterwards.

Re: The drive for 2.4.26

[Gregg Smith]

Yes, and only with the legacy build and then only with the IDE. Those 
files are static. If you build at the command line it should "just work."


When I built with apr 1.5 however apr_crypto_openssl would not build 
with openssl 1.1.0. I cannot see how that has changed..


On 4/29/2017 1:42 AM, Stefan Eissing wrote:

Is this a Windows issue? I built with 1.1.0e on MacOS and apr 1.5 and saw no 
problems.


Am 28.04.2017 um 22:26 schrieb Steffen :

I doubt now. It was based on a note in cvtdsp.pl.

Maybe it is only a .dsp and xml change, which I can apply to 1.5.

Maybe Gregg can shed some light on this ?



Op 28 apr. 2017 om 22:16 heeft William A Rowe Jr  het 
volgende geschreven:

Now that these are independent of one another, I think we can release before 1.6.x 
are released. We should just call out "New: OpenSSL 1.1.0 support! (Upcoming 
APR 1.6.x is required for this support.)




On Apr 28, 2017 2:56 PM, "Steffen"  wrote:
When with apr & apr-until 1.6 fine even more cooler.  Otherwise OpenSSL 1.1 not 
supported.

For OpenSSL 1.1 we need apr & apr-util 1.6 to build (e.g  apr_crypto_openssl 
for mod_session crypto)



Op 28 apr. 2017 om 14:14 heeft Jim Jagielski  het volgende 
geschreven:

It would be cool to have 2.4.26 released by ApacheCon, or even
by OSCON. There are, last I checked, 2 showstoppers on list for
2.4.26... Anyway we could address them and shoot for a T maybe
next Weds?

Re: svn commit: r1792912 - in /httpd/httpd/branches/2.4.x/modules/filters: mod_brotli.dsp mod_brotli.mak

[Gregg Smith]

No, libs/exe still land in the source root.


On 4/28/2017 8:35 AM, William A Rowe Jr wrote:

Wouldn't there be a corresponding change to LIBPATH?



On Thu, Apr 27, 2017 at 10:17 AM,   wrote:

Author: gsmith
Date: Thu Apr 27 15:17:57 2017
New Revision: 1792912

URL: http://svn.apache.org/viewvc?rev=1792912=rev
Log:
Per brotli-master include will move in 1.0.0
Prepare now, remove old location once 1.0.0 is released

Modified:
httpd/httpd/branches/2.4.x/modules/filters/mod_brotli.dsp
httpd/httpd/branches/2.4.x/modules/filters/mod_brotli.mak

Modified: httpd/httpd/branches/2.4.x/modules/filters/mod_brotli.dsp
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/filters/mod_brotli.dsp?rev=1792912=1792911=1792912=diff
==
--- httpd/httpd/branches/2.4.x/modules/filters/mod_brotli.dsp (original)
+++ httpd/httpd/branches/2.4.x/modules/filters/mod_brotli.dsp Thu Apr 27 
15:17:57 2017
@@ -43,7 +43,7 @@ RSC=rc.exe
 # PROP Ignore_Export_Lib 0
 # PROP Target_Dir ""
 # ADD BASE CPP /nologo /MD /W3 /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D 
"HAVE_ZUTIL_H" /FD /c
-# ADD CPP /nologo /MD /W3 /O2 /Oy- /Zi /I "../../include" /I "../../srclib/apr/include" /I "../../srclib/apr-util/include" /I 
"../../srclib/brotli/include" /D "NDEBUG" /D "WIN32" /D "_WINDOWS" /Fd"Release\mod_brotli_src" /FD /c
+# ADD CPP /nologo /MD /W3 /O2 /Oy- /Zi /I "../../include" /I "../../srclib/apr/include" /I "../../srclib/apr-util/include" /I 
"../../srclib/brotli/include" /I "../../srclib/brotli/c/include" /D "NDEBUG" /D "WIN32" /D "_WINDOWS" 
/Fd"Release\mod_brotli_src" /FD /c
 # ADD BASE MTL /nologo /D "NDEBUG" /win32
 # ADD MTL /nologo /D "NDEBUG" /mktyplib203 /win32
 # ADD BASE RSC /l 0x409 /d "NDEBUG"
@@ -75,7 +75,7 @@ PostBuild_Cmds=if exist $(TargetPath).ma
 # PROP Ignore_Export_Lib 0
 # PROP Target_Dir ""
 # ADD BASE CPP /nologo /MDd /W3 /EHsc /Zi /Od /D "WIN32" /D "_DEBUG" /D 
"_WINDOWS" /FD /c
-# ADD CPP /nologo /MDd /W3 /EHsc /Zi /Od /I "../../include" /I "../../srclib/apr/include" /I "../../srclib/apr-util/include" /I 
"../../srclib/brotli/include" /D "_DEBUG" /D "WIN32" /D "_WINDOWS" /D "HAVE_ZUTIL_H" 
/Fd"Debug\mod_brotli_src" /FD /c
+# ADD CPP /nologo /MDd /W3 /EHsc /Zi /Od /I "../../include" /I "../../srclib/apr/include" /I "../../srclib/apr-util/include" /I 
"../../srclib/brotli/include" /I "../../srclib/brotli/c/include" /D "_DEBUG" /D "WIN32" /D "_WINDOWS" /D "HAVE_ZUTIL_H" 
/Fd"Debug\mod_brotli_src" /FD /c
 # ADD BASE MTL /nologo /D "_DEBUG" /win32
 # ADD MTL /nologo /D "_DEBUG" /mktyplib203 /win32
 # ADD BASE RSC /l 0x409 /d "_DEBUG"

Modified: httpd/httpd/branches/2.4.x/modules/filters/mod_brotli.mak
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/filters/mod_brotli.mak?rev=1792912=1792911=1792912=diff
==
--- httpd/httpd/branches/2.4.x/modules/filters/mod_brotli.mak (original)
+++ httpd/httpd/branches/2.4.x/modules/filters/mod_brotli.mak Thu Apr 27 
15:17:57 2017
@@ -62,7 +62,7 @@ CLEAN :
 if not exist "$(OUTDIR)/$(NULL)" mkdir "$(OUTDIR)"

 CPP=cl.exe
-CPP_PROJ=/nologo /MD /W3 /Zi /O2 /Oy- /I "../../include" /I "../../srclib/apr/include" /I "../../srclib/apr-util/include" /I 
"../../srclib/brotli/include" /D "NDEBUG" /D "WIN32" /D "_WINDOWS" /Fo"$(INTDIR)\\" 
/Fd"$(INTDIR)\mod_brotli_src" /FD /c
+CPP_PROJ=/nologo /MD /W3 /Zi /O2 /Oy- /I "../../include" /I "../../srclib/apr/include" /I "../../srclib/apr-util/include" /I 
"../../srclib/brotli/include" /I "../../srclib/brotli/c/include" /D "NDEBUG" /D "WIN32" /D "_WINDOWS" /Fo"$(INTDIR)\\" 
/Fd"$(INTDIR)\mod_brotli_src" /FD /c

 .c{$(INTDIR)}.obj::
$(CPP) @<<
@@ -166,7 +166,7 @@ CLEAN :
 if not exist "$(OUTDIR)/$(NULL)" mkdir "$(OUTDIR)"

 CPP=cl.exe
-CPP_PROJ=/nologo /MDd /W3 /Zi /Od /I "../../include" /I "../../srclib/apr/include" /I "../../srclib/apr-util/include" /I 
"../../srclib/brotli/include" /D "_DEBUG" /D "WIN32" /D "_WINDOWS" /D "HAVE_ZUTIL_H" /Fo"$(INTDIR)\\" 
/Fd"$(INTDIR)\mod_brotli_src" /FD /EHsc /c
+CPP_PROJ=/nologo /MDd /W3 /Zi /Od /I "../../include" /I "../../srclib/apr/include" /I "../../srclib/apr-util/include" /I 
"../../srclib/brotli/include" /I "../../srclib/brotli/c/include" /D "_DEBUG" /D "WIN32" /D "_WINDOWS" /D "HAVE_ZUTIL_H" 
/Fo"$(INTDIR)\\" /Fd"$(INTDIR)\mod_brotli_src" /FD /EHsc /c

 .c{$(INTDIR)}.obj::
$(CPP) @<<

Re: The drive for 2.4.26

[Gregg Smith]

APR 1.6 is needed for apr_crypto_openssl, obviously.

ABS: Not sure. When I originally tried building w/ APR 1.5 it didn't 
work, but it didn't work with OpenSSL 1.1 and APR 1.6 either. That has 
now been fixed by Rainer. Have not tried 1.5/1.1.0 w/ abs yet so I 
simply don't know. Feel free to try it. I have no time today to do it.


cvtdsp.pl assumes 1.6 is needed due to those first attempts and may be 
inaccurate. It's easy to just remove the xml.mak regex for 1.6 that's 
part of cvtdsp.pl -ossl11 (), there is a separate -apr16 option 
for just the one change in APR (xml.mak's location). Maybe I should 
remove the part concerning APR 1.6 from the -ossl11 option.


Once APR 1.6 is released my plan is to make the change permanent next 
2.4.x then making the need for that conversion unneeded.


Openssl 1.0.2 is good till sometime in 2019, even 1.1.0 eol's before it 
does so we're stuck w/ cvtdsp.pl modifying the dsp files one way or 
another.


Anyone with commit access for apr can remove the part to modify for 1.6 
that is included in cvtdsp.pl -ossl110 (sub toossl1) if 1.6 really isn't 
needed for ABS.


Have a family member in the hospital who had surgery yesterday so this 
is my first time to even check mail since Wednesday morning. I have to 
go back to the hospital shortly.




On 4/28/2017 1:26 PM, Steffen wrote:

I doubt now. It was based on a note in cvtdsp.pl.

Maybe it is only a .dsp and xml change, which I can apply to 1.5.

Maybe Gregg can shed some light on this ?



Op 28 apr. 2017 om 22:16 heeft William A Rowe Jr  het 
volgende geschreven:

Now that these are independent of one another, I think we can release before 1.6.x 
are released. We should just call out "New: OpenSSL 1.1.0 support! (Upcoming 
APR 1.6.x is required for this support.)




On Apr 28, 2017 2:56 PM, "Steffen"  wrote:
When with apr & apr-until 1.6 fine even more cooler.  Otherwise OpenSSL 1.1 not 
supported.

For OpenSSL 1.1 we need apr & apr-util 1.6 to build (e.g  apr_crypto_openssl 
for mod_session crypto)



Op 28 apr. 2017 om 14:14 heeft Jim Jagielski  het volgende 
geschreven:

It would be cool to have 2.4.26 released by ApacheCon, or even
by OSCON. There are, last I checked, 2 showstoppers on list for
2.4.26... Anyway we could address them and shoot for a T maybe
next Weds?

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[Gregg Smith]

On 4/26/2017 7:53 AM, Jim Jagielski wrote:

Thanks! Are these the full diffs for Makefile?

On Apr 26, 2017, at 10:50 AM, Gregg Smith <g...@gknw.net> wrote:


On 4/26/2017 4:51 AM, Jim Jagielski wrote:



On Apr 25, 2017, at 4:34 PM, Evgeny Kotkov <evgeny.kot...@visualsvn.com> wrote:

Hi all,

I noticed that the version of mod_brotli that has been backported to 2.4.x
lacks a few Makefile changes from trunk.  This results in a failing Unix
build when mod_brotli is not being built.


Hmmm I can't recreate that here on CentOS or macOS.

Nevertheless, I know that the Makefiles were diff, but the
backport didn't include those diffs so I couldn't just apply
them after the fact, so I am +1 for adding them as a "new"
backport.


Tested both IDE and command line builds.
Commited r1792753



Yes, for the legacy build.
Includes the addition to BaseAddr.ref (which conflicts from trunk due to 
the different order in which modules have been added to 2.4).

Addition to the LoadModule section of the Windows httpd.conf.

We should be good to go all the way around.

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[Gregg Smith]

On 4/26/2017 4:51 AM, Jim Jagielski wrote:



On Apr 25, 2017, at 4:34 PM, Evgeny Kotkov  wrote:

Hi all,

I noticed that the version of mod_brotli that has been backported to 2.4.x
lacks a few Makefile changes from trunk.  This results in a failing Unix
build when mod_brotli is not being built.


Hmmm I can't recreate that here on CentOS or macOS.

Nevertheless, I know that the Makefiles were diff, but the
backport didn't include those diffs so I couldn't just apply
them after the fact, so I am +1 for adding them as a "new"
backport.


Tested both IDE and command line builds.
Commited r1792753

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[Gregg Smith]

Actually, I'll test here in a while and commit tomorrow.


On 4/25/2017 6:20 PM, Gregg Smith wrote:

I have one, command line makefiles and all. I just haven't had time to
run a test build yet though lloking at it looks fine, but I like to test
first.


On 4/25/2017 2:07 PM, Yann Ylavic wrote:

Hi Evgeny,

On Tue, Apr 25, 2017 at 10:34 PM, Evgeny Kotkov
<evgeny.kot...@visualsvn.com> wrote:


With the backport being in place in the 2.4.x branch, these changes
no longer
merge cleanly from trunk.  I can prepare a backport nomination for
them that
resolves the conflicts and add it to the 2.4.x STATUS.

What do you think?


+1


Regards,
Yann.

Index: Apache-apr2.dsw
===
--- Apache-apr2.dsw	(revision 1792168)
+++ Apache-apr2.dsw	(working copy)
@@ -1243,6 +1243,24 @@
 
 ###
 
+Project: "mod_brotli"=.\modules\filters\mod_brotli.dsp - Package Owner=<4>
+
+Package=<5>
+{{{
+}}}
+
+Package=<4>
+{{{
+Begin Project Dependency
+Project_Dep_Name libapr
+End Project Dependency
+Begin Project Dependency
+Project_Dep_Name libhttpd
+End Project Dependency
+}}}
+
+###
+
 Project: "mod_bucketeer"=.\modules\debugging\mod_bucketeer.dsp - Package Owner=<4>
 
 Package=<5>
Index: Apache.dsw
===
--- Apache.dsw	(revision 1792168)
+++ Apache.dsw	(working copy)
@@ -1483,6 +1483,27 @@
 
 ###
 
+Project: "mod_brotli"=.\modules\filters\mod_brotli.dsp - Package Owner=<4>
+
+Package=<5>
+{{{
+}}}
+
+Package=<4>
+{{{
+Begin Project Dependency
+Project_Dep_Name libapr
+End Project Dependency
+Begin Project Dependency
+Project_Dep_Name libaprutil
+End Project Dependency
+Begin Project Dependency
+Project_Dep_Name libhttpd
+End Project Dependency
+}}}
+
+###
+
 Project: "mod_bucketeer"=.\modules\debugging\mod_bucketeer.dsp - Package Owner=<4>
 
 Package=<5>
Index: build/installwinconf.awk
===
--- build/installwinconf.awk	(revision 1792168)
+++ build/installwinconf.awk	(working copy)
@@ -116,6 +116,7 @@
   print "#LoadModule authz_owner_module modules/mod_authz_owner.so" > dstfl;
   print "LoadModule authz_user_module modules/mod_authz_user.so" > dstfl;
   print "LoadModule autoindex_module modules/mod_autoindex.so" > dstfl;
+  print "#LoadModule brotli_module modules/mod_brotli.so" > dstfl;
   print "#LoadModule buffer_module modules/mod_buffer.so" > dstfl;
   print "#LoadModule cache_module modules/mod_cache.so" > dstfl;
   print "#LoadModule cache_disk_module modules/mod_cache_disk.so" > dstfl;
Index: BuildBin.dsp
===
--- BuildBin.dsp	(revision 1792168)
+++ BuildBin.dsp	(working copy)
@@ -39,7 +39,7 @@
 # PROP Use_Debug_Libraries 0
 # PROP Output_Dir ""
 # PROP Intermediate_Dir ""
-# PROP Cmd_Line "NMAKE /f makefile.win INSTDIR="\Apache2" LONG=Release _trydb _trylua _tryxml _tryssl _tryzlib _trynghttp2 _dummy"
+# PROP Cmd_Line "NMAKE /f makefile.win INSTDIR="\Apache2" LONG=Release _trydb _trylua _tryxml _tryssl _tryzlib _trynghttp2 _trybrotli _dummy"
 # PROP Rebuild_Opt ""
 # PROP Target_File "\Apache2\bin\httpd.exe"
 # PROP Bsc_Name ".\Browse\httpd.bsc"
@@ -58,7 +58,7 @@
 # PROP Use_Debug_Libraries 1
 # PROP Output_Dir ""
 # PROP Intermediate_Dir ""
-# PROP Cmd_Line "NMAKE /f makefile.win INSTDIR="\Apache2" LONG=Debug _trydb _trylua _tryxml _tryssl _tryzlib _trynghttp2 _dummy"
+# PROP Cmd_Line "NMAKE /f makefile.win INSTDIR="\Apache2" LONG=Debug _trydb _trylua _tryxml _tryssl _tryzlib _trynghttp2 _trybrotli _dummy"
 # PROP Rebuild_Opt ""
 # PROP Target_File "\Apache2\bin\httpd.exe"
 # PROP Bsc_Name ".\Browse\httpd.bsc"
Index: Makefile.win
===
--- Makefile.win	(revision 1792168)
+++ Makefile.win	(working copy)
@@ -268,6 +268,33 @@
 
 !ENDIF
 
+!IF EXIST("srclib\brotli")
+
+_trybrotli:
+!IF $(USEMAK) == 1
+	cd modules\filters
+	$(MAKE) $(MAKEOPT) -f mod_brotli.mak CFG="mod_brotli - Win32 $(LONG)" RECURSE=0 $(CTARGET)
+	cd ..\..
+!ELSEIF $(USESLN) == 1
+	devenv $(TLP).sln /useenv $(CTARGET) $(LONG) /project mod_brotli

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[Gregg Smith]

I have one, command line makefiles and all. I just haven't had time to 
run a test build yet though lloking at it looks fine, but I like to test 
first.



On 4/25/2017 2:07 PM, Yann Ylavic wrote:

Hi Evgeny,

On Tue, Apr 25, 2017 at 10:34 PM, Evgeny Kotkov
 wrote:


With the backport being in place in the 2.4.x branch, these changes no longer
merge cleanly from trunk.  I can prepare a backport nomination for them that
resolves the conflicts and add it to the 2.4.x STATUS.

What do you think?


+1


Regards,
Yann.

Re: The drive for 2.4.26

[Gregg Smith]

This is ApacheBench, Version 2.3 <$Revision: 1750960 $>
Same result with trunk, it just hangs.

Glad it's not just Windows!

On 4/20/2017 9:48 AM, Rainer Jung wrote:

Am 20.04.2017 um 16:31 schrieb Gregg Smith:

ABS doesn't work with openssl 1.1.0, on windows anyway. It builds
without warning yet doesn't work.

abs https://www.domain.com
just sits there forever and never completes or shows anything.

I cannot imagine this being a windows only problem.


Any chance you can try the trunk version:

https://svn.apache.org/repos/asf/httpd/httpd/trunk/support/ab.c

The chances are good, that you can simply replace the ab.c source file
and recompile. No need to compile a complete httpd trunk. If the trunk
version works, we could focus on the delta which is not huge but
noticeable.

Thanks!

Rainer


On 4/20/2017 3:24 AM, Jim Jagielski wrote:

We are very, very close to being in a releasable state... looks
like just 1 show-stopper. If we also want to wait until APR 1.6
is released, we can also look at having redis/memcached parity in
socache as well, which would be good for 2.4.26...

Thoughts?

PS: it would be great to have this out by ApacheCon next month.

Re: The drive for 2.4.26

[Gregg Smith]

ABS doesn't work with openssl 1.1.0, on windows anyway. It builds 
without warning yet doesn't work.


abs https://www.domain.com
just sits there forever and never completes or shows anything.

I cannot imagine this being a windows only problem.

On 4/20/2017 3:24 AM, Jim Jagielski wrote:

We are very, very close to being in a releasable state... looks
like just 1 show-stopper. If we also want to wait until APR 1.6
is released, we can also look at having redis/memcached parity in
socache as well, which would be good for 2.4.26...

Thoughts?

PS: it would be great to have this out by ApacheCon next month.

Re: svn commit: r1791192 - /httpd/httpd/branches/2.4.x/support/abs.mak

[Gregg Smith]

On 4/12/2017 9:12 PM, William A Rowe Jr wrote:

On Wed, Apr 12, 2017 at 5:31 PM,   wrote:

Author: gsmith
Date: Wed Apr 12 22:31:15 2017
New Revision: 1791192

URL: http://svn.apache.org/viewvc?rev=1791192=rev
Log:
Add another include since applink.c has been moved in
the OpenSSL source. More info:
http://marc.info/?t=14919286431=1=2

Modified:
httpd/httpd/branches/2.4.x/support/abs.mak

Modified: httpd/httpd/branches/2.4.x/support/abs.mak
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/support/abs.mak?rev=1791192=1791191=1791192=diff
==
--- httpd/httpd/branches/2.4.x/support/abs.mak (original)
+++ httpd/httpd/branches/2.4.x/support/abs.mak Wed Apr 12 22:31:15 2017
@@ -28,7 +28,7 @@ NULL=nul
 !IF "$(_HAVE_OSSL110)" == "1"
 SSLCRP=libcrypto
 SSLLIB=libssl
-SSLINC=/I ../srclib/openssl/include
+SSLINC=/I ../srclib/openssl/include /I ../srclib/openssl/ms


Question (untested)... does this work for local builds, since ms is not
in the include  scope?


No, will revert.

It will have to be done as a prebuild step, placing a copy into 
include/openssl.

Re: svn commit: r1790999 - in /httpd/httpd/branches/2.4.x: Makefile.win docs/manual/platform/win_compiling.xml modules/ssl/mod_ssl.mak support/ab.c support/abs.mak

[Gregg Smith]

On 4/11/2017 5:19 PM, William A Rowe Jr wrote:

On Tue, Apr 11, 2017 at 5:49 PM, Gregg Smith <g...@gknw.net> wrote:


They will say fix ours. Bottom line, it's been moved from
include/openssl/applink.c to ms/applink.c

So, ok, will have to add /ms to the includes or do you have a better
suggestion?


That suggests that OpenSSL make install deploys ms/applink.c.
Guessing they do not. Pointer to the thread/github issue?

If it does not, I would suggest no change, and document to the user
that they must sweep ms/applink.c to the include/openssl/ directory
when they are working with openssl 'installed'. If you would like to
add ../../srcdir/openssl/ms/ to includes, a not-present directory is
no real obstacle to getting the build to work.

It's upstream that is responsible for a usable $PREFIX result tree.
The sources should be expected to be gone.



No applink.c is installed to PREFIX/include/openssl. I neglected to 
consider building with cmake, my bad.


Adding the include is the easiest way to deal with this.

Re: svn commit: r1790999 - in /httpd/httpd/branches/2.4.x: Makefile.win docs/manual/platform/win_compiling.xml modules/ssl/mod_ssl.mak support/ab.c support/abs.mak

[Gregg Smith]

On 4/11/2017 3:16 PM, William A Rowe Jr wrote:

On Tue, Apr 11, 2017 at 11:36 AM,   wrote:

Author: gsmith
Date: Tue Apr 11 16:36:25 2017
New Revision: 1790999

URL: http://svn.apache.org/viewvc?rev=1790999=rev
Log:
Retro win32 command-line build

allow building with OpenSSL 1.1.0

ab.c (abs)
--
applink.c has been moved in this version of OpenSSL


--- httpd/httpd/branches/2.4.x/support/ab.c (original)
+++ httpd/httpd/branches/2.4.x/support/ab.c Tue Apr 11 16:36:25 2017
@@ -175,8 +175,12 @@ typedef STACK_OF(X509) X509_STACK_TYPE;
  * by the OpenSSL library build to another CRT used by the ab.exe build.
  * This became especially problematic with Visual Studio 2015.
  */
+#if (OPENSSL_VERSION_NUMBER >= 0x101fL)
+#include <../ms/applink.c>
+#else
 #include 
 #endif
+#endif

This change is absolutely wrong, please revert. On no planet does
one '../' out of the system/additional includes path.

I would guess you are trying to get at a file in a source package?
There's no assurance we are looking at a source package, LIBS
and INCLUDES may be set up to point to the installed build+devel
resources.

If the defect is in OpenSSL, let's coordinate the fix upstream.



They will say fix ours. Bottom line, it's been moved from 
include/openssl/applink.c to ms/applink.c


So, ok, will have to add /ms to the includes or do you have a better 
suggestion?

Re: [VOTE] Release httpd-2.2.32

[Gregg Smith]

On 1/9/2017 10:21 AM, William A Rowe Jr wrote:

The pre-release candidate tarballs of Apache legacy httpd 2.2.32
can be found in;

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

Thanks to all for patches and reviews to get us to this point.
STATUS file is updated to reflect end of maintenance Jul 1 '17.

Your votes, please?

+/-1
[ ] Release 2.2.32 as legacy GA


+1
VC9, XP/7/2012 R2

Thanks Bill for R/Ming and to all those who helped get this out.

Re: Mod_brotli, C89 & NetWare - finale

[Gregg Smith]

Hi Norm,

Actually, log2 is not needed. It's cmake that forces it on us.
Look at fast_log.h line 131

#if (defined(_MSC_VER) && _MSC_VER <= 1700) || \
(defined(__ANDROID_API__) && __ANDROID_API__ < 18)
  /* Visual Studio 2012 and Android API levels < 18 do not have the log2()
   * function defined, so we use log() and a multiplication instead. */
  return log((double)v) * LOG_2_INV;
#else
  return log2((double)v);
#endif

You may define _MSC_VER=1 at the command line when compiling and it 
should work for you.  In CMakeList.txt I just remove the check for 
log2(), lines 96-113, before using.


Cheers,
G

On 11/27/2016 3:38 AM, NormW wrote:

G/E,
After some head scratching/bashing and research:

Brotli.lib has several places that use log2(), which was not defined 
in C89 (AFAIK), although the function could be kludged easily enough 
as it uses C89 functions in its own routine.


Although NetWare was derived using a C89 compiler, its math.h shows 
signs of its early development, in that a number of MATHs macro's 
resolve not to values but to LibC functions, which means they can't be 
used in 'const' assignments... hence const  = INFINITY fails to 
compile. (It was on the ToDo list it seems but the ship sank before it 
made the top of the list.) Tweaking math.h while possible, doesn't 
make for much sense, but mod_brotli does at least compile without 
issue; well almost.


The only C89 issue (AFAICT) is the following patch, which should allow 
any other C89 (with a more up to date OS ;-( ) to compile it, which 
NetWare's CW can do for the likes of Apache2, Lua, Zlib, NGHTTP2, OSSL 
and a bunch of others.



Index: modules/filters/mod_brotli.c
===
--- modules/filters/mod_brotli.c(revision 1771539)
+++ modules/filters/mod_brotli.c(working copy)
@@ -240,7 +240,7 @@
 output = BrotliEncoderTakeOutput(ctx->state, _len);
 ctx->total_out += output_len;

-b = apr_bucket_transient_create(output, output_len,
+b = apr_bucket_transient_create((const char *)output, 
output_len,

ctx->bb->bucket_alloc);
 APR_BRIGADE_INSERT_TAIL(ctx->bb, b);

@@ -289,7 +289,7 @@
 output = BrotliEncoderTakeOutput(ctx->state, _len);
 ctx->total_out += output_len;

-b = apr_bucket_heap_create(output, output_len, NULL,
+b = apr_bucket_heap_create((const char *)output, output_len, 
NULL,

ctx->bb->bucket_alloc);
 APR_BRIGADE_INSERT_TAIL(ctx->bb, b);
 }

Norm

Re: Fwd: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c

[Gregg Smith]

On 6/15/2016 9:20 AM, William A Rowe Jr wrote:

In building httpd.exe, some users don't build and install openssl. It isn't
going
to be possible to simply #include  without some
conditional
test. OpenSSL itself is partly the culprit, for not having an
APPLINK_REQUIRED
style macro conditional. But we can work around this in the cmake tests.



This is why the patch creator put this inside a HAVE_OPENSSL block so 
ab.exe did not get this added. abs (at least on the dsp et. al.) is not 
built unless there is OpenSSL present.



I'll look at making this a standard bit of the httpd 2.4 build. We can
likely
add a user-toggled flag to the os/win32/os.h?


Seems to me this is not needed .

Re: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c

[Gregg Smith]

On 6/14/2016 6:33 PM, William A Rowe Jr wrote:

Gregg, if you would vet the patch as applied to trunk/2.4/2.2, I'd
appreciate it.
On Jun 14, 2016 3:37 PM,  wrote:
I built 2.4 and 2.2 in VC14 and tested with VC11 Openssl dlls. Being 
down a machine (with all VC runtimes from 9-14 installed) and short on 
free time that is the best I can do right now.


2.4
abs worked.
Last Changed Author: jailletc36
Last Changed Rev: 1748500

2.2
abs worked.
Last Changed Author: wrowe
Last Changed Rev: 1748461

So it looks good. I'll go over trunk in a couple days when things settle 
down on my end.

Re: h2_proxy_util.c, is this going make 2.4.21?

[Gregg Smith]

sorry, that was not supposed to go to list.

On 6/14/2016 4:01 PM, Gregg Smith wrote:

Hi Steffen,

Attached is a svn pull from about 1 hour after I committed my changes. 
No need to wait for tag if you would rather get a jump on testing. To 
maybe hit the 3 or 4 days after when you find bugs.


Gregg



On 6/14/2016 2:17 AM, Steffen wrote:


Then I wait for the Tag.

You know with me, that http2 in real live testing needs extended time 
for testing. Happened more then once  that a crash/issue was showing 
up,after 3/4 days. So hope that 72 hours is enough.


Steffen


On Tuesday 14/06/2016 at 11:09, Stefan Eissing  wrote:

Steffen,

unfortunately not. They now contains changes that only compile with 
a 2.4.21 httpd.


-Stefan



Am 14.06.2016 um 11:06 schrieb Steffen <i...@apachelounge.com>:

I rather like to test before tagging.

Can you apply these changes for my testing also to  Git ?

Steffen

On Tuesday 14/06/2016 at 10:54, Stefan Eissing wrote:


I just backported the h2_proxy_util.c change in r1748359. It also 
uses the back ported ap_cstr_casecmp* instead of its own copies. I 
tried to update the win build files appropriately, but am unable 
to check the correctness.


Gregg: please commit your changes when awake enough. Hopefully Jim 
can keep his fingers from the tag button long enough...


Cheers,

   Stefan



Am 13.06.2016 um 22:40 schrieb William A Rowe Jr 
<wr...@rowe-clan.net>:


On Mon, Jun 13, 2016 at 1:59 PM, Gregg Smith <g...@gknw.net> wrote:
I have the to connect this module in the traditional windows 
build but as of right now it's using h2_util.c which Bill had an 
objection to. See his comments 
http://marc.info/?l=apache-httpd-dev=146543811201820=2


So to me that seems to be a -1 to mod_proxy_http2, at minimum on 
Windows. In trunk Stefan seems to have chosen option 3 in Bill's 
list and that is h2_proxy_util.c.


If I knew that was going to be backported I would add the rest of 
the bits needed to use h2_proxy_util.c. If it is not going to 
make it, then I will not commit anything and there will be no 
mod_proxy_http2 in 2.4.21 on Windows. If this gets in overnight 
and you tag in the morning, I may not be out of bed yet due to 
the time difference.


That's where my concern is. Make sense?

Shouldn't be a concern. I'm mildly concerned about the 
single-level namespace
collisions on Unix, but because the .so object is pre-linked to 
its own functions
before anything is imported/exported, mod_http2.so should be 
using h2_utils.o
and mod_proxy_http2.so should be using h2_proxy_utils.o, even 
without any
additional namespace protection. A third module trying to use the 
functions of
those two modules could cause headaches, but that can be 
addressed later.


Windows has two-level namespaces, so there is no ambiguity 
between symbols
in one .so (.dll) and a second, unless you are simultaneously 
linking a module

to both of these modules.

I accept Stefan's proposed fix for the time being, and we can 
certainly make

this simpler on trunk in the future.

Cheers,

Bill

Re: h2_proxy_util.c, is this going make 2.4.21?

[Gregg Smith]

I've committed my changes and the module builds and loads but that is as 
far as I got.


Thanks everyone,

Gregg

On 6/14/2016 4:47 AM, Stefan Eissing wrote:

Am 14.06.2016 um 13:18 schrieb Jim Jagielski<j...@jagunet.com>:

Let's hold off on the tag then... How about if I bump the T
from today to Thurs?

+1

I would like to have any Window build issues detected and resolved before the 
tag.

-Stefan


On Jun 14, 2016, at 5:17 AM, Steffen<i...@apachelounge.com>  wrote:

Then I wait for the Tag.

You know with me, that http2 in real live testing needs extended time for 
testing. Happened more then once  that a crash/issue was showing up,after 3/4 
days. So hope that 72 hours is enough.

Steffen

On Tuesday 14/06/2016 at 11:09, Stefan Eissing wrote:

Steffen,

unfortunately not. They now contains changes that only compile with a 2.4.21 
httpd.

-Stefan


Am 14.06.2016 um 11:06 schrieb Steffen<i...@apachelounge.com>:

I rather like to test before tagging.

Can you apply these changes for my testing also to Git ?

Steffen

On Tuesday 14/06/2016 at 10:54, Stefan Eissing wrote:

I just backported the h2_proxy_util.c change in r1748359. It also uses the back 
ported ap_cstr_casecmp* instead of its own copies. I tried to update the win 
build files appropriately, but am unable to check the correctness.

Gregg: please commit your changes when awake enough. Hopefully Jim can keep his 
fingers from the tag button long enough...

Cheers,

 Stefan


Am 13.06.2016 um 22:40 schrieb William A Rowe Jr<wr...@rowe-clan.net>:

On Mon, Jun 13, 2016 at 1:59 PM, Gregg Smith<g...@gknw.net>  wrote:
I have the to connect this module in the traditional windows build but as of right now 
it's using h2_util.c which Bill had an objection to. See his comments 
http://marc.info/?l=apache-httpd-dev=146543811201820=2

So to me that seems to be a -1 to mod_proxy_http2, at minimum on Windows. In 
trunk Stefan seems to have chosen option 3 in Bill's list and that is 
h2_proxy_util.c.

If I knew that was going to be backported I would add the rest of the bits 
needed to use h2_proxy_util.c. If it is not going to make it, then I will not 
commit anything and there will be no mod_proxy_http2 in 2.4.21 on Windows. If 
this gets in overnight and you tag in the morning, I may not be out of bed yet 
due to the time difference.

That's where my concern is. Make sense?

Shouldn't be a concern. I'm mildly concerned about the single-level namespace
collisions on Unix, but because the .so object is pre-linked to its own 
functions
before anything is imported/exported, mod_http2.so should be using h2_utils.o
and mod_proxy_http2.so should be using h2_proxy_utils.o, even without any
additional namespace protection. A third module trying to use the functions of
those two modules could cause headaches, but that can be addressed later.

Windows has two-level namespaces, so there is no ambiguity between symbols
in one .so (.dll) and a second, unless you are simultaneously linking a module
to both of these modules.

I accept Stefan's proposed fix for the time being, and we can certainly make
this simpler on trunk in the future.

Cheers,

Bill

Re: h2_proxy_util.c, is this going make 2.4.21?

[Gregg Smith]

I have the to connect this module in the traditional windows build but 
as of right now it's using h2_util.c which Bill had an objection to. See 
his comments http://marc.info/?l=apache-httpd-dev=146543811201820=2


So to me that seems to be a -1 to mod_proxy_http2, at minimum on 
Windows. In trunk Stefan seems to have chosen option 3 in Bill's list 
and that is h2_proxy_util.c.


If I knew that was going to be backported I would add the rest of the 
bits needed to use h2_proxy_util.c. If it is not going to make it, then 
I will not commit anything and there will be no mod_proxy_http2 in 
2.4.21 on Windows. If this gets in overnight and you tag in the morning, 
I may not be out of bed yet due to the time difference.


That's where my concern is. Make sense?


On 6/13/2016 11:43 AM, Jim Jagielski wrote:

What needs to be done?


On Jun 13, 2016, at 2:20 PM, Gregg Smith<g...@gknw.net>  wrote:

Hi Stefan,

Any plans to backport this before Jim tags 2.4.21 tomorrow?

Thanks,

Gregg

h2_proxy_util.c, is this going make 2.4.21?

[Gregg Smith]

Hi Stefan,

Any plans to backport this before Jim tags 2.4.21 tomorrow?

Thanks,

Gregg

Re: [POLL] Commitment to 2.2.x lifecycle? (Was: End of the road of 2.2.x maintenance?)

[Gregg Smith]

On 5/25/2016 8:11 AM, William A Rowe Jr wrote:

  *) I intend to help maintain/test 2.2.x releases over the next [_6__] mos
  *) I intend to backport/review 2.2.x security patches over the next [_0__] mos

Re: svn commit: r1745517 - /httpd/httpd/branches/2.4.x/support/win32/ApacheMonitor.c

[Gregg Smith]

On 5/25/2016 11:14 AM, William A Rowe Jr wrote:

Your comment doesn't match the code, and I think you have the condition
inverted, _setargv() worked for decades, and only was broken in the more
recent MSVC's.


Typo, should be 1800 in log, I'll change it. I may revert it now that I 
dug & found $(VCINSTALLDIR) . If that's in VC6 then it's usable all the 
way up the line and the setargv.obj can just be added to the dsp/mak files.



My thought is to unilaterally change this to the unicode implementation,
because 1. ANSI-only are dead Windows OS's, and 2. Getting the utf-8
thing right in this app is becoming a big headache.

Thoughts?


If it deals with this then why not!
Apachemonitor itself could use another way of figuring out what it's 
running on also as GetVersionExA is gone and the code in VC > 11 making 
it work won't last forever I'd suspect. I've been looking into that and 
MS gives an nice example at 
https://msdn.microsoft.com/en-us/library/windows/desktop/ms725491%28v=vs.85%29.aspx




On Wed, May 25, 2016 at 11:29 AM,  wrote:


Author: gsmith
Date: Wed May 25 16:29:59 2016
New Revision: 1745517

URL: http://svn.apache.org/viewvc?rev=1745517=rev
Log:
backport r1745516
_setargv will not compile on _MSC_VER<  1700
MS documentation's example simply does not work.
Disabe for now, Apachemonitor still works.

Modified:
 httpd/httpd/branches/2.4.x/support/win32/ApacheMonitor.c

Modified: httpd/httpd/branches/2.4.x/support/win32/ApacheMonitor.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/support/win32/ApacheMonitor.c?rev=1745517=1745516=1745517=diff

==
--- httpd/httpd/branches/2.4.x/support/win32/ApacheMonitor.c (original)
+++ httpd/httpd/branches/2.4.x/support/win32/ApacheMonitor.c Wed May 25
16:29:59 2016
@@ -1586,8 +1586,10 @@ int WINAPI WinMain(HINSTANCE hInstance,
  #ifdef UNICODE
  __wargv = CommandLineToArgvW(GetCommandLineW(),&__argc);
  #else
+#if defined(_MSC_VER)&&  _MSC_VER<  1800
  _setargv();
  #endif
+#endif

  if ((__argc == 2)&&  (_tcscmp(__targv[1], _T("--kill")) == 0))
  {

mod_proxy_hcheck and Windows

[Gregg Smith]

I got to playing around with trunk over the weekend and ran into this;

.\mod_proxy_hcheck.c(925) : error C2440: 'function' : cannot convert 
from 'void *(__cdecl *)(apr_thread_t *,void *)' to 'apr_thread_start_t'
.\mod_proxy_hcheck.c(925) : warning C4022: 'apr_thread_pool_push' : 
pointer mismatch for actual parameter 2


Cheers

Re: End of the road of 2.2.x maintenance?

[Gregg Smith]

On 5/16/2016 11:03 AM, Eric Covener wrote:

On Tue, May 10, 2016 at 1:38 PM, William A Rowe Jr  wrote:

Are we ready to start the 12 month countdown as of the next/final bug
fix release of 2.2, and highlight this in both the 2.2 and 2.4 announce
broadcasts?

One shortcoming of a 12 month countdown is that some folks will not be
able to plan/pitch/budget/execute a migration in 12 calendar months
because of bad timing.

As long as we're not committing to releases in this window, I'd
personally be okay with pushing out to 18 months re: the later
feedback in this thread. I don't feel too strongly about>  12 months
notice, but I will still have a 2.2-derivative in support beyond that
window anyway.


We should just pick a date right now (say 31/12/2017) and begin 
announcing (website/download page/mail lists) it now. Include that one 
last release will come out before the end of the year and it will be 
patches only after final release and until EOL date. That is 18 and a 
half months to EOL with a final release within 6 and a half. This should 
leave any admin time to plan/pitch/budget/execute a migration and give 
everyone a firm date to EOL to plan around.

mod_proxy_hcheck ouch in Windows

[Gregg Smith]

This one I cannot figure out

.\mod_proxy_hcheck.c(925) : error C2440: 'function' : cannot convert 
from 'void *(__cdecl *)(apr_thread_t *,void *)' to 'apr_thread_start_t'


- Gregg -

Re: svn commit: r1741419 [1/4] - in /httpd/httpd/branches/2.4.x: ./ modules/http2/

[Gregg Smith]

Oops, one more.
h2_request.c(452) : warning C4003: not enough actual parameters for 
macro 'APLOGNO'


On 4/28/2016 10:17 AM, Stefan Eissing wrote:

Ah, will alloc a new one tomorrow. Should be one left. Thanks.


Am 28.04.2016 um 18:57 schrieb Gregg Smith<g...@gknw.net>:


On 4/28/2016 5:43 AM, ic...@apache.org wrote:
Author: icing
Date: Thu Apr 28 12:43:02 2016
New Revision: 1741419

URL: http://svn.apache.org/viewvc?rev=1741419=rev
Log:
mod_http2: backport of 1.5.2 to 2.4.x

Added:
 httpd/httpd/branches/2.4.x/modules/http2/h2_bucket_beam.c
   - copied, changed from r1739303, 
httpd/httpd/trunk/modules/http2/h2_bucket_beam.c
 httpd/httpd/branches/2.4.x/modules/http2/h2_bucket_beam.h
   - copied, changed from r1739303, 
httpd/httpd/trunk/modules/http2/h2_bucket_beam.h

Hi Stefan,

FYI
h2_bucket_beam.c(338) : warning C4003: not enough actual parameters for macro 
'APLOGNO'
Maybe you can recycle one from one of the removed files, not sure about that 
however since they were used in 2.4.20.

- Gregg -

Re: svn commit: r1741419 [1/4] - in /httpd/httpd/branches/2.4.x: ./ modules/http2/

[Gregg Smith]

On 4/28/2016 5:43 AM, ic...@apache.org wrote:

Author: icing
Date: Thu Apr 28 12:43:02 2016
New Revision: 1741419

URL: http://svn.apache.org/viewvc?rev=1741419=rev
Log:
mod_http2: backport of 1.5.2 to 2.4.x

Added:
 httpd/httpd/branches/2.4.x/modules/http2/h2_bucket_beam.c
   - copied, changed from r1739303, 
httpd/httpd/trunk/modules/http2/h2_bucket_beam.c
 httpd/httpd/branches/2.4.x/modules/http2/h2_bucket_beam.h
   - copied, changed from r1739303, 
httpd/httpd/trunk/modules/http2/h2_bucket_beam.h


Hi Stefan,

FYI
h2_bucket_beam.c(338) : warning C4003: not enough actual parameters for 
macro 'APLOGNO'
Maybe you can recycle one from one of the removed files, not sure about 
that however since they were used in 2.4.20.


- Gregg -

Re: [VOTE] Release Apache httpd 2.4.20 as GA

[Gregg Smith]

On 4/4/2016 9:20 AM, Jim Jagielski wrote:

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

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

Vote will last the normal 72 hrs.

[X] +1: Good to go

Built: VC9 & 14 w/ .dsp, VC11 w/ Bill's recent .mak files
Tested: XP & Vista x86, Win 7, 8.1 & Server 2012 R2 x64
OpenSSL 1.0.2g & 1.0.1s
nghttp2 1.9.2
PCRE 8.38
APR/APU/API 1.5.2/1.5.4/1.2.1
LibXML 2.9.3
ZLib 1.2.8

Thanks for R/Ming Jim

Re: state of h2 (long)

[Gregg Smith]

Hi Stefan,

I've had a real lack of time lately to do much on trunk's mod_http2 on 
the windows side. The new mod_proxy_http2 requires a few functions from 
mod_http2 and with what time I have had I have been unsuccessful 
figuring out how to get these functions exported. So if you (or anyone 
else) can figure this out, I'd appreciate it.


Gregg

On 2/26/2016 9:06 AM, Stefan Eissing wrote:

Things winding down here a bit before the weekend (at least I try) and I thought
I'd summarize a bit the state of HTTP/2 in our little project, because...well, 
some
might be interested and certainly no one has the time to follow all my crazy 
submits.

* trunk<->  2.4.x
   the version in 2.4.x has gathered a bit dust, as we made several tweaks in 
trunk
   in regard to async connection handling and scoreboard updates. These have 
all been
   backported, except one. Once that is through, I'll make a backport of 
mod_http2,
   so that 2.4.x gets all the nice new things.

* nice new things
   in trunk we have the following additions:
   - http/2 connections get queued properly when they become idle on the event 
mpm.
 that should be nice for people with many connections or long keepalives 
configured.
   - timeouts and keepalive timeouts are respected as for http/1 connections, 
no extra
 configuration.
   - stability: with the interim releases in github and the help of nice 
people, several
 improvements have been made here and the 1.2.5 github has no reported open 
blockers,
 hanging connections or segfaults. All those changes are in trunk.
   - server push: the module now remembers in each open connection which 
resources
 have already been pushed, using hash digests. This also implements an 
outsketched
 extension https://datatracker.ietf.org/doc/draft-kazuho-h2-cache-digest/ 
whereby
 clients can send a highly compressed digest of the resources they have. 
This is
 very early and experimental and we'll see how/if browsers adapt this and 
how
 it will change over time.
   - To offload worker threads, the module allows a number of file handles to 
have
 open. So, ideally, when serving static content, workers just lookup the 
file,
 return and the master connections streams them out. This number existed 
before
 as number per master connection. Now this number is multiplied by the 
number of
 workers and made a process wide pool where h2 connections can borrow 
amounts.
 Still, I am not totally satisfied with this. This should not be 
configurable, but
 httpd itself should check for ulimits of the process and configure itself, 
I think.
   - the scoreboard shows more information for h2 connections, such as its 
connection
 state and some stream statistics. Maybe the h2 workers should show up in a 
separate
 section on day...
  127.0.0.1 http/1.1test2.example.org:12345 wait, streams: 
1/100/100/0/0 (open/recv/resp/push/rst)
   - request engines! which leads us to:

  * mod_proxy_http2
is configured just like other proxy modules with by using 'h2' or 'h2c' as 
url prefix
in the configuration directives.


BalancerMember "h2://test2.example.org:12346"

 ProxyPass "/h2proxy" "balancer://h2-local"
 ProxyPassReverse "/h2proxy" "balancer://h2-local"
 
 Initially, it used one h2 connection for one request. The connection, and 
the http2
 session associated with it, was reused via the nice proxy infrastructure.

 This is how things still are when the original connection is http/1.1
 When this is http/2 itself, however, the first such request will register a
 "request engine" that will accept more requests while the initial one is 
still
 being served and use the same backend connection for it. When the last 
assigned
 request is done, it unregisters and dissolves into fine mist.
 The connection and h2 session stays as before, so a new request can reuse 
the connection
 in a new engine.

 This works quite (but not 100%) reliable at the moment. There are still 
some races when
 requests are sent out while the backend is already shutting down and the 
retry does
 not catch all cases.

 Important here is that requests for engines process all the usual hooks 
and filters
 and yaddayadda of our infrastructure, just like with http/1.1. This works 
as follows:

 - incoming request is handed to a worker thread as is done for all by 
mod_http2
 - httpd/proxy identifies the handler of mod_proxy_http2 as the responsible
 - mod_proxy_http2 finds out what backend it shall talk to and ask from 
mod_http2
   (if present, the usual optionals) if there is already an engine for this 
backend,
   and that it is willing to host one if there is not.
 - mod_http2, if it has one, *freezes* the task for this request (which 
holds the
   replacements for the core input/output filters on this slave connection) 
and
   returns 

Re: h2_conn.c r1727604 crashing on windows

[Gregg Smith]

Hi Stefan,

It works!

Thanks!

On 2/17/2016 1:04 AM, Stefan Eissing wrote:

Hi Gregg,

could you check if r1730798 works for you? Thanks!

//Stefan


Am 17.02.2016 um 06:08 schrieb Gregg Smith<g...@gknw.net>:

Hi Stefan,

Windows doesn't seems to like this.
Short call stack and locals in attached.

Regards,

Gregg

h2_conn.c r1727604 crashing on windows

[Gregg Smith]

Hi Stefan,

Windows doesn't seems to like this.
Short call stack and locals in attached.

Regards,

Gregg
httpd-trunk at r1727604

APR  1.5.2
APR-UTIL 1.5.4
PCRE 8.38
SSL  1.0.2f
NGHTTP2  1.7.0

Call Stack
--

>   mod_http2.so!h2_slave_create(conn_rec * master=0x02cbc2b0, apr_pool_t * 
> p=0x01a6e208, apr_thread_t * thread=0x01a6c2b0, apr_socket_t * 
> socket=0x01a6c2d0)  Line 262 + 0x5 bytes C
mod_http2.so!execute(apr_thread_t * thread=0x01a6c2b0, void * 
wctx=0x02cd2380)  Line 66 + 0x1b bytesC
libapr-1.dll!dummy_worker(void * opaque=0x01a6c2b0)  Line 79 + 0xa 
bytesC
msvcr90.dll!70c23433()  
[Frames below may be incorrect and/or missing, no symbols loaded for 
msvcr90.dll]   
msvcr90.dll!70c234c7()  
kernel32.dll!75ead4d1() 
ntdll.dll!77401593()
ntdll.dll!77401566()


Locals
--

-   master  0x02cbc2b0 {pool=0x02cd0138 base_server=0x01a3c100 
vhost_lookup_data=0x ...}conn_rec *
pool0x02cd0138  apr_pool_t *
+   base_server 0x01a3c100 {process=0x019cd0a0 next=0x01a3b768 
error_fname=0x01a3c7a8 "logs/error.log" ...} server_rec *
vhost_lookup_data   0x  void *
-   local_addr  0x02cbc188 {pool=0x02cbc0e8 hostname=0x 
 servname=0x  ...}apr_sockaddr_t *
pool0x02cbc0e8  apr_pool_t *
+   hostname0x char *
+   servname0x char *
port0x01bb  unsigned short
family  0x0017  int
salen   0x001c  int
ipaddr_len  0x0010  int
addr_str_len0x002e  int
ipaddr_ptr  0x02cbc1b8  void *
+   next0x {pool=??? hostname=??? servname=??? ...} 
apr_sockaddr_t *
+   sa  {sin={...} sin6={...} } 
-   client_addr 0x02cbc1d0 {pool=0x02cbc0e8 hostname=0x 
 servname=0x  ...}apr_sockaddr_t *
pool0x02cbc0e8  apr_pool_t *
+   hostname0x char *
+   servname0x char *
port0xd192  unsigned short
family  0x0017  int
salen   0x001c  int
ipaddr_len  0x0010  int
addr_str_len0x002e  int
ipaddr_ptr  0x02cbc200  void *
+   next0x {pool=??? hostname=??? servname=??? ...} 
apr_sockaddr_t *
+   sa  {sin={...} sin6={...} } 
+   client_ip   0x02cbc370 "::1"char *
+   remote_host 0x char *
+   remote_logname  0x char *
+   local_ip0x02cbc340 "::1"char *
+   local_host  0x char *
id  0x003e  long
conn_config 0x02cd0178  ap_conf_vector_t *
notes   0x02cd0200  apr_table_t *
+   input_filters   0x02cee2b8 {frec=0x01a6be40 ctx=0x02cd23e0 
next=0x02cee090 ...} ap_filter_t *
+   output_filters  0x02cd0530 {frec=0x01a1f660 ctx=0x 
next=0x02cd0550 ...} ap_filter_t *
sbh 0x02cbc2a8  void *
bucket_alloc0x02cbe0f0  apr_bucket_alloc_t *
+   cs  0x {state=??? sense=??? }   conn_state_t *
data_in_input_filters   0x  int
data_in_output_filters  0x  int
clogging_input_filters  0x  unsigned int
double_reverse  0x  int
aborted 0x  unsigned int
keepalive   AP_CONN_UNKNOWN ap_conn_keepalive_e
keepalives  0x  int
+   log 0x {module_levels=??? level=??? }   const 
ap_logconf *
+   log_id  0x const char *
current_thread  0x02cbc3a0  apr_thread_t *
+   slaves  0x02cd0358 {pool=0x02cd0138 elt_size=0x0004 
nelts=0x ...}   apr_array_header_t *
+   master  0x {pool=??? base_server=??? 
vhost_lookup_data=??? ...} conn_rec *
ctx 0x  void *
suspended_baton 0x  void *
+   requests0x02cd03c0 {pool=0x02cd0138 elt_size=0x0004 
nelts=0x ...}   apr_array_header_t *
+   empty   0x02cd0428 {p=0x02cd0138 list={...} 
bucket_alloc=0x02cbe0f0 }   apr_bucket_brigade *
filters 0x02cd0448  apr_hash_t *
async_filter0x  int
p   0x01a6e208  apr_pool_t *

Re: mod_proxy_http2

[Gregg Smith]

On 2/8/2016 9:07 AM, Stefan Eissing wrote:

PS. I did not update Windows Makefiles. I feel bad.


Don't, I need to play catch-up anyway :)

Should this be in modules/proxy like all the rest of the mod_proxy_* 
modules?
I personally do not care, I was just thinking (which in itself can be 
dangerous).

Re: [VOTE] Release Apache httpd 2.4.18 as GA

[Gregg Smith]

+1 Various flavors of VC/Windows


On 12/8/2015 12:38 PM, Jim Jagielski wrote:

The pre-release test tarballs for Apache httpd 2.4.18 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.18 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!

Re: svn commit: r1712300 [1/2] - /httpd/httpd/trunk/modules/http2/

[Gregg Smith]

On 11/3/2015 6:33 AM, ic...@apache.org wrote:

Author: icing
Date: Tue Nov  3 14:33:11 2015
New Revision: 1712300

URL: http://svn.apache.org/viewvc?rev=1712300=rev
Log:
rework of output handling on stream/session close, rework of cleartext (http:) 
output to pass buckets to core filters, splitting of stream/io memory pools for 
stability and less sync

Added:
 httpd/httpd/trunk/modules/http2/h2_bucket_eoc.c
 httpd/httpd/trunk/modules/http2/h2_bucket_eoc.h
 httpd/httpd/trunk/modules/http2/h2_bucket_eos.c
 httpd/httpd/trunk/modules/http2/h2_bucket_eos.h
Modified:

...

 httpd/httpd/trunk/modules/http2/h2_util.c

Added: httpd/httpd/trunk/modules/http2/h2_bucket_eoc.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/h2_bucket_eoc.c?rev=1712300=auto
==

...

+
+AP_DECLARE(apr_bucket *) h2_bucket_eoc_make(apr_bucket *b,
+h2_session *session)


No :) we cannot export with AP_DELARE in modules on Windows because we 
need to keep them separate from the AP_DECLARE functions we are going to 
be importing from core.


.\h2_util.c(727) : error C2491: 'h2_transfer_brigade' : definition of 
dllimport function not allowed
.\h2_bucket_eos.c(60) : error C2491: 'h2_bucket_eos_make' : definition 
of dllimport function not allowed
.\h2_bucket_eos.c(74) : error C2491: 'h2_bucket_eos_create' : definition 
of dllimport function not allowed
.\h2_bucket_eos.c(101) : error C2491: 'ap_bucket_type_h2_eos' : 
definition of dllimport data not allowed
.\h2_bucket_eoc.c(60) : error C2491: 'h2_bucket_eoc_make' : definition 
of dllimport function not allowed
.\h2_bucket_eoc.c(74) : error C2491: 'h2_bucket_eoc_create' : definition 
of dllimport function not allowed
.\h2_bucket_eoc.c(101) : error C2491: 'ap_bucket_type_h2_eoc' : 
definition of dllimport data not allowed


If we take a page from other modules (mod_dav/proxy/ssl) we can see the 
need to come up with an private set of declares.

I have the attached patch ready to commit.
...

+AP_DECLARE_DATA const apr_bucket_type_t ap_bucket_type_h2_eoc = {
+"H2EOC", 5, APR_BUCKET_METADATA,
+bucket_destroy,
+bucket_read,
+apr_bucket_setaside_noop,
+apr_bucket_split_notimpl,
+apr_bucket_shared_copy
+};
+


>>> Nit <<<
Should we really be declaring anything for export with an ap_* in a 
loadable module? I thought the ap_* name was reserved for core only, I 
may be wrong.



Index: modules/http2/h2_bucket_eoc.c
===
--- modules/http2/h2_bucket_eoc.c	(revision 1712389)
+++ modules/http2/h2_bucket_eoc.c	(working copy)
@@ -54,7 +54,7 @@
 return APR_SUCCESS;
 }
 
-AP_DECLARE(apr_bucket *) h2_bucket_eoc_make(apr_bucket *b, 
+H2_DECLARE(apr_bucket *) h2_bucket_eoc_make(apr_bucket *b, 
 h2_session *session)
 {
 h2_bucket_eoc *h;
@@ -68,7 +68,7 @@
 return b;
 }
 
-AP_DECLARE(apr_bucket *) h2_bucket_eoc_create(apr_bucket_alloc_t *list,
+H2_DECLARE(apr_bucket *) h2_bucket_eoc_create(apr_bucket_alloc_t *list,
   h2_session *session)
 {
 apr_bucket *b = apr_bucket_alloc(sizeof(*b), list);
@@ -97,7 +97,7 @@
 }
 }
 
-AP_DECLARE_DATA const apr_bucket_type_t ap_bucket_type_h2_eoc = {
+const apr_bucket_type_t H2_DECLARE_DATA ap_bucket_type_h2_eoc = {
 "H2EOC", 5, APR_BUCKET_METADATA,
 bucket_destroy,
 bucket_read,
Index: modules/http2/h2_bucket_eoc.h
===
--- modules/http2/h2_bucket_eoc.h	(revision 1712389)
+++ modules/http2/h2_bucket_eoc.h	(working copy)
@@ -19,13 +19,13 @@
 struct h2_session;
 
 /** End Of HTTP/2 SESSION (H2EOC) bucket */
-AP_DECLARE_DATA extern const apr_bucket_type_t ap_bucket_type_h2_eoc;
+H2_DECLARE_DATA extern const apr_bucket_type_t ap_bucket_type_h2_eoc;
 
 
-AP_DECLARE(apr_bucket *) h2_bucket_eoc_make(apr_bucket *b, 
+H2_DECLARE(apr_bucket *) h2_bucket_eoc_make(apr_bucket *b, 
 struct h2_session *session);
 
-AP_DECLARE(apr_bucket *) h2_bucket_eoc_create(apr_bucket_alloc_t *list,
+H2_DECLARE(apr_bucket *) h2_bucket_eoc_create(apr_bucket_alloc_t *list,
   struct h2_session *session);
 
 #endif /* mod_http2_h2_bucket_eoc_h */
Index: modules/http2/h2_bucket_eos.c
===
--- modules/http2/h2_bucket_eos.c	(revision 1712389)
+++ modules/http2/h2_bucket_eos.c	(working copy)
@@ -54,7 +54,7 @@
 return APR_SUCCESS;
 }
 
-AP_DECLARE(apr_bucket *) h2_bucket_eos_make(apr_bucket *b, 
+H2_DECLARE(apr_bucket *) h2_bucket_eos_make(apr_bucket *b, 
h2_stream *stream)
 {
 h2_bucket_eos *h;
@@ -68,7 +68,7 @@
 return b;
 }
 
-AP_DECLARE(apr_bucket *) 

Re: No luck with `Protocols h2`

[Gregg Smith]

Hi Jacob,
On 10/9/2015 4:47 PM, Jacob Champion wrote:

Stefan,

I'm trying to test mod_http2 for the 2.4.17 release, but I cannot for 
the life of me get ALPN and the h2 protocol working together. h2c 
seems to work, as does http/1.1 over TLS. My hope is that I'm just 
missing a config directive somewhere; can anyone else confirm that h2 
negotiation is working for them?


I've attached a few files; hopefully they help.
- working.txt shows the debug log for an HTTP/1.1 Firefox request that 
ends in a 404. Note "ALPN selected protocol: 'http/1.1'", so ALPN 
appears to be functioning there.
- not_working.txt shows the same request, but after I've added a 
`Protocols h2 http/1.1`line and restarted the server. Note the 
"h2_h2, error reading 24 bytes speculative" line with status "End of 
file found". Firefox sees a response of zero bytes and does nothing.
- httpd.conf is my server configuration. (It's the result of trying to 
strip out huge pieces of the actual conf to see where the error 
started from; sorry for the mess.)


It's not just Firefox: nghttp also complains that h2 is not being 
negotiated and refuses to continue with the request. I saw the 
no-matching-SSL-virtual-host error first and thought that might have 
something to do with it, but adding ServerAliases didn't seem to help 
anything.


I'm running on Ubuntu 14.04 with Apache 2.4.17, APR 2.0, OpenSSL 
1.0.2d, nghttp2 1.3.4.


Thanks for any wisdom you can provide,
--Jacob

I'm betting it's the cipher being used ECDHE-RSA-AES256-SHA. OpenSSL says
ECDHE-RSA-AES256-SHA = TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

There is a big list of blacklisted ciphers in the RFC 
https://httpwg.github.io/specs/rfc7540.html#BadCipherSuites

You will find that cipher on the list.

I have no real recommendation for you but the RFC states all 
implementations must support
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 or OpenSSL's equivalent 
ECDHE-RSA-AES128-GCM-SHA256.

So it's a starting point.

Happy http/2-ing,

Gregg

Re: [VOTE] Release Apache httpd 2.4.17 as GA

[Gregg Smith]

On 10/9/2015 10:40 AM, 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.
Not a vote, I haven't gotten that far yet. It's been pointed out to me 
that on our potential first release of the new module that the docs for 
it are wrong : (  I suppose this happens when something is renamed at a 
relatively last minute.


The docs still state the module identifier as  h2_module which of course 
it's http2_module.

Re: T of 2.4.17 this week

[Gregg Smith]

On 10/8/2015 3:57 AM, Steffen wrote:

Jus curious, why is e.g. LUA there ?


Probably because when mod_lua was added it got added and not the case 
when mod_proxy_html and mod_xml2enc got added nor did I think about it 
when adding mod_h2. My fault.


This is beyond the scope of httpd's source and was originally for the 
old contributed binary distributions but I see no reason not to include 
them anyway.


Done for:
Trunk: r1707640
2.4.x: r1707641

Re: AW: mod_h2 CTR (Was: Re: svn commit: r1705257 - /httpd/httpd/trunk/modules/http2/config.m4)

[Gregg Smith]

On 9/25/2015 8:56 AM, Plüm, Rüdiger, Vodafone Group wrote:



-Ursprüngliche Nachricht-
Von: Plüm, Rüdiger, Vodafone Group
Gesendet: Freitag, 25. September 2015 17:51
An: dev@httpd.apache.org
Betreff: AW: mod_h2 CTR (Was: Re: svn commit: r1705257 -
/httpd/httpd/trunk/modules/http2/config.m4)




-Ursprüngliche Nachricht-
Von: Jim Jagielski [mailto:j...@jagunet.com]
Gesendet: Freitag, 25. September 2015 17:46
An: dev@httpd.apache.org
Betreff: Re: mod_h2 CTR (Was: Re: svn commit: r1705257 -
/httpd/httpd/trunk/modules/http2/config.m4)

In any case, let's not bike-shed on what we call it, or whatever...

Let's focus on deciding if we are cool with it being CTR once it's
folded into 2.4.x and "handling" it as we do mod_lua.

+1 on CTR for mod_h2 in 2.4.x


Just to clarify: CTR only on the code in modules/http2. All changes / 
adjustments that might be needed to mod_ssl should stay RTC.

+1 as detailed by Rüdiger.
+1 to experimental and same note as mod_lua in docs.

Re: svn move modules/http2 modules/h2 ?

[Gregg Smith]

http2 is more descriptive for the module's purpose, even if the name is 
mod_h2. I like it where it is.

- 0

On 9/22/2015 5:08 AM, Stefan Eissing wrote:

+0.5

h2 ftw! (but there is also a mod_mime in the http dir, so I do not really feel 
strongly about this)


Am 22.09.2015 um 14:05 schrieb Yann Ylavic:

I'm confused about the sources being in modules/http2 and the module
being mod_h2 (configured with --enable-h2, ...), it seems to be the
only one like this.

+1 for me...

bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

Re: proposed backport of mod_h2 - v4

[Gregg Smith]

In core-h2-all-in-one-v4.patch line 8586
+if (!offers || ap_array_contains(offers, *protos)) {
the old ap_array_contains is in use

On 9/5/2015 12:21 AM, Stefan Eissing wrote:

yes, it should. where do you not see it?

(i wish we'd use branches instead of this patch file madness)


Am 05.09.2015 um 06:12 schrieb Gregg Smith<g...@gknw.net>:

Shouldn't this be ap_array_str_contains now in h2_switch.c?

+while (*protos) {
+/* Add all protocols we know (tls or clear) and that
+ * are part of the offerings (if there have been any).
+ */
-->+if (!offers || ap_array_contains(offers, *protos)) {
+ap_log_cerror(APLOG_MARK, APLOG_TRACE1, 0, c,
+  "proposing protocol '%s'", *protos);

Re: proposed backport of mod_h2 - v4

[Gregg Smith]

Shouldn't this be ap_array_str_contains now in h2_switch.c?

+while (*protos) {
+/* Add all protocols we know (tls or clear) and that
+ * are part of the offerings (if there have been any).
+ */
-->+if (!offers || ap_array_contains(offers, *protos)) {
+ap_log_cerror(APLOG_MARK, APLOG_TRACE1, 0, c,
+  "proposing protocol '%s'", *protos);

Re: r1701005 httpd-trunk\server\protocols.c

[Gregg Smith]

On 9/3/2015 9:23 PM, NormW wrote:

On 4/09/2015 9:05 AM, Yann Ylavic wrote:

On Fri, Sep 4, 2015 at 12:52 AM, NormW  wrote:

Hi again,
Pushing passed previous problem, now arrive at:


D:\Projects\svn\httpd-trunk\server>svn diff
Index: protocol.c
===
--- protocol.c  (revision 1701142)
+++ protocol.c  (working copy)
@@ -1981,10 +1981,10 @@
  server_rec *s,
  apr_array_header_t 
*choices)

  {
+apr_array_header_t *proposals;
  apr_pool_t *pool = r? r->pool : c->pool;
  core_server_config *conf =
ap_get_core_module_config(s->module_config);
  const char *protocol = NULL, *existing = ap_get_protocol(c);;
-apr_array_header_t *proposals;


Hm, aren't there other/many places in the httpd code where non
initialized variables are declared after the initialized ones?


I am hoping my compiler is at least consistent!
Not sure of what the rules are well enough to be an expert. I know 
Windows can be as pedantic as mine. See if Gregg asks for a similar 
change first, just to be sure.

Norm

No it does not build on VC9 as is.
.\server\protocol.c(1987) : error C2143: syntax error : missing ';' 
before 'type'

.\server\protocol.c(1998) : error C2065: 'proposals' : undeclared identifier

But fresh eyes see the ;; on the end of line 1986
const char *protocol = NULL, *existing = ap_get_protocol(c);;
Why this trips our compilers I have no idea but one ; should be sufficient.
fixed in r1701165

Re: r1700777 - h2_stream.c

[Gregg Smith]

Hi Norm,

I need it too.
done in r1700917

Gregg

On 9/2/2015 5:07 PM, NormW wrote:

hi,
If not mistaken, on the latest httpd-trunk\modules\http2 update:


D:\Projects\svn\httpd-trunk\modules\http2>svn diff
Index: h2_session.c
===
--- h2_session.c(revision 1700915)
+++ h2_session.c(working copy)
@@ -259,8 +259,9 @@
const nghttp2_frame *frame, void *userp)
 {
 /* This starts a new stream. */
+int rv;
 (void)ngh2;
-int rv = stream_open((h2_session *)userp, frame->hd.stream_id);
+rv = stream_open((h2_session *)userp, frame->hd.stream_id);
 if (rv != NGHTTP2_ERR_CALLBACK_FAILURE) {
   /* on_header_cb or on_frame_recv_cb will dectect that stream
  does not exist and submit RST_STREAM. */


Otherwise compiles fine.
Norm

Re: proposed backport of mod_h2

[Gregg Smith]

Hi Stefan,

core patch:
needs r1694950 and may require a minor mmn bump, at least that is what I 
took away from the discussion about it over this commit.


h2 patch:
needs r1700917

Thanks,

Gregg


On 9/2/2015 7:10 AM, Stefan Eissing wrote:

As in r1700829. Regression tests run (after small change on apache version 
check in h2.t) on OS X for me.

Cheers,

   Stefan

bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

Re: proposed backport, mod_h2 github release

[Gregg Smith]

On 8/26/2015 6:44 AM, Stefan Eissing wrote:

I just submitted my first backport STATUS update. Hope I did everything ok, 
otherwise please let me know.

For backporting mod_h2 to 2.4.x, I decided to make it in two parts: one is the 
patch to core/mod_ssl that introduces Protocols. That is now in STATUS.


Needs r1693918, other than that all seems ok so far :)

Re: protocols and mod_h2 consolidation

[Gregg Smith]

Stefan,

Changes worked great. Thanks.

Gregg

On 8/25/2015 3:43 AM, Stefan Eissing wrote:

Gregg,

I just checked in changes that should fix the warnings you mentioned. Thanks 
for reviewing this. As to the SERVER_PROTOCOL, I have no idea yet what may 
cause this.

//Stefan


Am 25.08.2015 um 06:11 schrieb Gregg Smithg...@gknw.net:

Hi,

On 8/24/2015 9:29 AM, Stefan Eissing wrote:


I hope this works for everyone. The next weeks might be a good time to think 
about it and propose any changes and correct my mistakes.

There are two things that go bump on my lowest non-eol version of MSVC.
h2_worker.c
.\h2_worker.c(113) : error C2440: 'function' : cannot convert from 'void 
*(__cdecl *)(apr_thread_t *,void *)' to 'apr_thread_start_t'
.\h2_worker.c(113) : warning C4022: 'apr_thread_create' : pointer mismatch for 
actual parameter 3

Casting execute to apr_thread_start_t (what apr_thread_create expects) seems to 
quiet the compiler and FireFox seems to work with it.

h2_session.c
.\h2_session.c(1079) : error C2440: 'type cast' : cannot convert from 'int' to 
'nghttp2_data_source'
.\h2_session.c(1081) : warning C4047: 'initializing' : 'int' differs in levels 
of indirection from 'nghttp2_data_source_read_callback'

This cast to a union type, this MSVC version's docs on Unions has a note in the 
comments mentioning;

We recommend that you do not use a union to cast data from one data type to 
another because union members occupy the same address in memory.

There is no data-conversion support for unions. The results of interchanging 
writes and reads between union members of different types are unpredictable and 
depend on a variety of reasons.


They are evidently enforcing this. I just removed the cast and it builds and 
Firefox seems to work.

Other nits of interest or not;
h2_stream_set.c
.\h2_stream_set.c(139) : warning C4028: formal parameter 2 different from 
declaration

The function is prototyped as: h2_stream_set_match_fn *match
but in h2_stream_set.c it is: h2_stream_set_match_fn match

I get 2 different results for the $ENV{'SERVER_PROTOCOL'} in my perl script depending on the 
machine. My server gives me HTTP/1.1 and running locally on my build machine I get 
INCLUDED. Firefox says it is HTTP/2.0 200 OK so both results in this $ENV seem 
incorrect. I'm not sure why the difference as mod_h2 is configured same on both.

Regards,
Gregg






green/bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

Re: protocols and mod_h2 consolidation

[Gregg Smith]

On 8/25/2015 5:57 PM, William A Rowe Jr wrote:

On Aug 24, 2015 11:43 PM, Gregg Smithg...@gknw.net  wrote:

On 8/24/2015 9:29 AM, Stefan Eissing wrote:


I hope this works for everyone. The next weeks might be a good time to

think about it and propose any changes and correct my mistakes.

There are two things that go bump on my lowest non-eol version of MSVC.
h2_worker.c
.\h2_worker.c(113) : error C2440: 'function' : cannot convert from 'void

*(__cdecl *)(apr_thread_t *,void *)' to 'apr_thread_start_t'

.\h2_worker.c(113) : warning C4022: 'apr_thread_create' : pointer

mismatch for actual parameter 3

Casting execute to apr_thread_start_t (what apr_thread_create expects)

seems to quiet the compiler and FireFox seems to work with it.

That sounds most unsafe.  Is this a mismatch between DECLARE and
DECLARE_NONSTD?

Working right now on Linux but will take a few min to look at both issues
you flagged.

I'm sure it was, but I wanted it to build. I did not commit that.
Stefen has dealt with these issues properly I'd imagine in r1697634

Re: protocols and mod_h2 consolidation

[Gregg Smith]

Hi,

On 8/24/2015 9:29 AM, Stefan Eissing wrote:


I hope this works for everyone. The next weeks might be a good time to think 
about it and propose any changes and correct my mistakes.


There are two things that go bump on my lowest non-eol version of MSVC.
h2_worker.c
.\h2_worker.c(113) : error C2440: 'function' : cannot convert from 'void 
*(__cdecl *)(apr_thread_t *,void *)' to 'apr_thread_start_t'
.\h2_worker.c(113) : warning C4022: 'apr_thread_create' : pointer 
mismatch for actual parameter 3


Casting execute to apr_thread_start_t (what apr_thread_create expects) 
seems to quiet the compiler and FireFox seems to work with it.


h2_session.c
.\h2_session.c(1079) : error C2440: 'type cast' : cannot convert from 
'int' to 'nghttp2_data_source'
.\h2_session.c(1081) : warning C4047: 'initializing' : 'int' differs in 
levels of indirection from 'nghttp2_data_source_read_callback'


This cast to a union type, this MSVC version's docs on Unions has a note 
in the comments mentioning;


We recommend that you do not use a union to cast data from one data 
type to another because union members occupy the same address in memory.


There is no data-conversion support for unions. The results of 
interchanging writes and reads between union members of different 
types are unpredictable and depend on a variety of reasons.




They are evidently enforcing this. I just removed the cast and it builds 
and Firefox seems to work.


Other nits of interest or not;
h2_stream_set.c
.\h2_stream_set.c(139) : warning C4028: formal parameter 2 different 
from declaration


The function is prototyped as: h2_stream_set_match_fn *match
but in h2_stream_set.c it is: h2_stream_set_match_fn match

I get 2 different results for the $ENV{'SERVER_PROTOCOL'} in my perl 
script depending on the machine. My server gives me HTTP/1.1 and 
running locally on my build machine I get INCLUDED. Firefox says it is 
HTTP/2.0 200 OK so both results in this $ENV seem incorrect. I'm not 
sure why the difference as mod_h2 is configured same on both.


Regards,
Gregg

Re: svn commit: r1694950 - in /httpd/httpd/trunk: include/http_request.h modules/http/http_request.c

[Gregg Smith]

On 8/10/2015 11:44 AM, William A Rowe Jr wrote:

On Mon, Aug 10, 2015 at 12:31 PM, Gregg Smithg...@gknw.net  wrote:


Hi,

I guess a minor at least.

I did not add, remove or change the structure of the function, I simply
made it available to modules. Does that warrant a major bump?


Never a major - that is reserved for changing the signature of functions
or members of structures that are catastrophic for previously compiled
modules.  This is not one of those :)

The previous absence of these exports was simply a bug, I don't see
a reason to bump the version minor for bug fixing.

If users were looking to determine compatibility, e.g. on the 2.4 released
branch, I might have another opinion, but during trunk development, we
fix it and move on.  A previously compiled module simply wouldn't have
any insight on these functions so correcting it doesn't break what they
were already aware of


Thanks Christophe for bringing it up.
Thanks Bill and Rüdiger for the answer. I was sure it was not a major 
bump yet was foggy on the minor. My feeling on it was as Bill stated in 
his last sentence above.


G

Re: svn commit: r1694950 - in /httpd/httpd/trunk: include/http_request.h modules/http/http_request.c

[Gregg Smith]

Hi,

I guess a minor at least.

I did not add, remove or change the structure of the function, I simply 
made it available to modules. Does that warrant a major bump?




On 8/9/2015 10:40 PM, Marion  Christophe JAILLET wrote:

Hi,

doesn't it require a minor ap_mmn.h bump ?

cj

Le 10/08/2015 05:30, gsm...@apache.org a écrit :

Author: gsmith
Date: Mon Aug 10 03:30:25 2015
New Revision: 1694950

URL: http://svn.apache.org/r1694950
Log:
ap_process_request needs exportation for use in mod_h2 on Windows

Modified:
 httpd/httpd/trunk/include/http_request.h
 httpd/httpd/trunk/modules/http/http_request.c

Modified: httpd/httpd/trunk/include/http_request.h
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/include/http_request.h?rev=1694950r1=1694949r2=1694950view=diff
== 


--- httpd/httpd/trunk/include/http_request.h (original)
+++ httpd/httpd/trunk/include/http_request.h Mon Aug 10 03:30:25 2015
@@ -316,7 +316,7 @@ AP_DECLARE(void) ap_allow_standard_metho
   * the response to the client
   * @param r The current request
   */
-void ap_process_request(request_rec *r);
+AP_DECLARE(void) ap_process_request(request_rec *r);
/* For post-processing after a handler has finished with a request.
   * (Commonly used after it was suspended)

Modified: httpd/httpd/trunk/modules/http/http_request.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/http_request.c?rev=1694950r1=1694949r2=1694950view=diff
== 


--- httpd/httpd/trunk/modules/http/http_request.c (original)
+++ httpd/httpd/trunk/modules/http/http_request.c Mon Aug 10 03:30:25 
2015

@@ -363,7 +363,7 @@ void ap_process_async_request(request_re
  ap_process_request_after_handler(r);
  }
  -void ap_process_request(request_rec *r)
+AP_DECLARE(void) ap_process_request(request_rec *r)
  {
  apr_bucket_brigade *bb;
  apr_bucket *b;

Re: Building for NetWare /1 - For Your Consideration

[Gregg Smith]

Argh!

Hi Norm,

Can you attach this patch to the emain, not just paste it into the body 
of the message?

I'll assume this is for trunk and 2.4.

Cheers,

Gregg


On 7/24/2015 5:22 PM, NormW wrote:

Hi,
The NetWare Gurus seem to be on holidays. For your consideration:

Index: modules/cache/NWGNUsocachshmcb
===
--- modules/cache/NWGNUsocachshmcb(revision 1692595)
+++ modules/cache/NWGNUsocachshmcb(working copy)
@@ -28,6 +28,7 @@
 $(SRC)/include \
 $(SERVER)/mpm/netware \
 $(NWOS) \
+$(STDMOD)/generators \
 $(EOLIST)

 #
Needed so NWGNUsocachshmcb can find mod_status.h
Index: modules/cache/NWGNUsocachdbm
===
--- modules/cache/NWGNUsocachdbm(revision 1692595)
+++ modules/cache/NWGNUsocachdbm(working copy)
@@ -28,6 +28,7 @@
 $(SRC)/include \
 $(SERVER)/mpm/netware \
 $(NWOS) \
+$(STDMOD)/generators \
 $(EOLIST)

 #
Needed so NWGNUsocachdbm can find mod_status.h
Index: modules/dav/fs/mod_dav_fs.c
===
--- modules/dav/fs/mod_dav_fs.c(revision 1692595)
+++ modules/dav/fs/mod_dav_fs.c(working copy)
@@ -17,7 +17,9 @@
 #include httpd.h
 #include http_config.h
 #include apr_strings.h
+#if !defined(WIN32)  !defined(NETWARE)
 #include ap_config_auto.h
+#endif

 #include mod_dav.h
 #include repos.h
Needed so mod_dav_fs.c doesn't try to load ap_config_auto.h. AFAICT 
also not needed by WIN32.

Give me a prod if this format isn't useful.
Norm

Re: Building for NetWare /1 - For Your Consideration

[Gregg Smith]

On 7/24/2015 5:22 PM, NormW wrote:

Hi,
The NetWare Gurus seem to be on holidays. For your consideration:

Index: modules/cache/NWGNUsocachshmcb
===
--- modules/cache/NWGNUsocachshmcb(revision 1692595)
+++ modules/cache/NWGNUsocachshmcb(working copy)
@@ -28,6 +28,7 @@
 $(SRC)/include \
 $(SERVER)/mpm/netware \
 $(NWOS) \
+$(STDMOD)/generators \
 $(EOLIST)

 #
Needed so NWGNUsocachshmcb can find mod_status.h
Index: modules/cache/NWGNUsocachdbm
===
--- modules/cache/NWGNUsocachdbm(revision 1692595)
+++ modules/cache/NWGNUsocachdbm(working copy)
@@ -28,6 +28,7 @@
 $(SRC)/include \
 $(SERVER)/mpm/netware \
 $(NWOS) \
+$(STDMOD)/generators \
 $(EOLIST)

 #
Needed so NWGNUsocachdbm can find mod_status.h
Index: modules/dav/fs/mod_dav_fs.c
===
--- modules/dav/fs/mod_dav_fs.c(revision 1692595)
+++ modules/dav/fs/mod_dav_fs.c(working copy)
@@ -17,7 +17,9 @@
 #include httpd.h
 #include http_config.h
 #include apr_strings.h
+#if !defined(WIN32)  !defined(NETWARE)
 #include ap_config_auto.h
+#endif

 #include mod_dav.h
 #include repos.h
Needed so mod_dav_fs.c doesn't try to load ap_config_auto.h. AFAICT 
also not needed by WIN32.

Give me a prod if this format isn't useful.
Norm

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

[Gregg Smith]

On 7/15/2015 9:44 AM, William A Rowe Jr wrote:

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


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

Thanks for the quick turnaround RM!

Re: building httpd 2.2 on windows automation question.

[Gregg Smith]

On 7/14/2015 12:09 PM, Andy Wang wrote:

link.exe -lib @C:\Users\runtime\AppData\Local\Temp\nm9E02.tmp
c:\Program Files (x86)\Microsoft Visual Studio 
10.0\VC\BIN\nmake.exe -

nologo -f libaprutil.mak  CFG=libaprutil - Win32 Release RECURSE=0
if not exist .\Release/ mkdir .\Release
tempfile.bat
libaprutil.mak(1494) : fatal error U1054: cannot create inline file 
'tempfile.ba

t'
Stop.


I've run into this on VC11/Win7x64 more than once. I think I just 
restarted the build again and it has always gone through. Microsoft says 
a tempfile.bat already exists with a read-only attribute so it evidently 
has started creating the file before removing the prior one.


I remember an e-mail thread with you about building the makefile and 
dep files and how they weren't actually in the unix source and there 
were gaps where the windows source wasn't updated - which is why I 
needed to figure out how to build from the vanilla unix sources.  Did 
this change? Because I could swear the unix sources didn't have some 
of this stuff before.


I was evidently wrong, I'm looking at httpd-2.2.29.tar.gz as well as the 
2.2.30 tag and I see them there.  The .dep for mod_ssl is locked to 
OpenSSL = 0.9.8 but that is an easy fix and done with r1691074. I 
believe the Windows build is CTR.


I ran builds of 2.2.head using the included mak files and Yann's patch, 
all went well on VC9/Vista, VC10/2003r2  VC11/Win7x64.


Give it another try with 2.2.31 when it arrives, hopefully tomorrow.

Re: building httpd 2.2 on windows automation question.

[Gregg Smith]

You know 2.2 has .mak files in the source. They've been given no love in 
a long time but nothing major has changed for them to need it AFAIK. 
Those should make your automating life simple.

nmake /f makefile.win [options] installr


On 7/14/2015 9:03 AM, Andy Wang wrote:



On 07/14/2015 10:53 AM, Jeff Trawick wrote:



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



Nor should it be :)
Not for 2.2 at least.

Honestly, I'd like to get all our customers on 2.2 to 2.4 asap.  It 
would save me time and energy, but I know it ain't happening anytime 
soon.


FYI, the start of the thread about EOL'ing 2.2 ALMOST got me enough 
momentum to make the change.


So right now, the most I can do to make my life easier is to make the 
2.2 build process as invisible as possible.

Re: [VOTE] Release Apache httpd 2.4.16 as GA

[Gregg Smith]

On 7/10/2015 1: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.


[X] +1: Good to go

PS: Hopefully, 4th time's the charm!


Looking good, thanks for RMing.

MSVC '08, '12  '13
Tested on Windows XP/2003/Vista/7/8.1

Re: minor APR 1.5.2 build error on Windows

[Gregg Smith]

On 6/26/2015 1:54 AM, Stefan Hett wrote:

On 6/26/2015 4:55 AM, Gregg Smith wrote:

On 6/25/2015 10:51 AM, Stefan Hett wrote:

Hi Gregg,

On 6/22/2015 3:58 AM, Stefan Hett wrote:

Hi Gregg,

On 6/22/2015 2:49 AM, Stefan Hett wrote:

Hi,

I just tested building APR 1.5.2 from source on windows, 
following the instructions from the readme file.


compiling (aka: nmake -f Makefile.win) succeeded without 
problems, but the following install command (aka: nmake -f 
Makefile.win PREFIX=FOO install) failed with return code 0x1:


copy Release/libapr-1.pdb ..\apr-dist\bin\ .y
The system cannot find the file specified.
NMAKE : fatal error U1077: 'copy' : return code '0x1'
Stop.

Without looking at the build script I assume that the PDB is not 
created for Release builds and therefore the file is missing.


Maybe worth either adjusting the linker/compiler settings so the 
PDB is also generated in Release builds or adding a 
file-existence-check prior to the copy operation, so building 
doesn't issue that error?


For me that's not a problem here. Just thought might be good to 
raise that point so that user experience with APR could be 
improved.


But it is there, look at the Link line in libapr.mak
/pdb:$(OUTDIR)\libapr-1.pdb

It didn't get produced for some reason. What Visual C++ version 
are you using?

Using Visual Studio 2010 SP1 here.

I'm not that familiar with APR internals. So pardon me if I'm 
wrong here.
I assume you are refering to apr/libapr.mak here. For instance in 
line 174.


I can see that the /pdb-parameter is specified. However I don't 
see the /debug parameter here. To my knowledge the /pdb parameter 
just specifies the output filename for the PDB. It doesn't 
actually specify that the PDB is to be generated (for which the 
/Debug parameter would be used for). Also see: 
https://msdn.microsoft.com/en-us/library/kwx19e36.aspx


Am I on the wrong page here?


I don't think so but yes, line 174, /debug is right after the /pdb 
switch.

tal:no /pdb:$(OUTDIR)\libapr-1.pdb /debug /out:$

http://svn.apache.org/viewvc/apr/apr/tags/1.5.2/libapr.mak?view=annotate 



I just got back and checked this issue out once more. Of course you 
are right here. The linker settings seem to be fine. I just realized 
that in the build-directory (apr/Release) there indeed is a 
generated pdb-file, but it's called libapr.pdb.
Looking through the libapr.mak-file I didn't get a clue how it could 
name the pdb without the -1-suffix...


When building libapr I get these linker warnings:
1C:\Program Files 
(x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(990,5): 
warning MSB8012: 
TargetPath(E:\[delete]SVNTest\SVN\apr\.\Release\libapr.dll) does not 
match the Linker's OutputFile property value 
(E:\[delete]SVNTest\SVN\apr\Release\libapr-1.dll). This may cause 
your project to build incorrectly. To correct this, please make sure 
that $(OutDir), $(TargetName) and $(TargetExt) property values match 
the value specified in %(Link.OutputFile).
1C:\Program Files 
(x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(992,5): 
warning MSB8012: TargetName(libapr) does not match the Linker's 
OutputFile property value (libapr-1). This may cause your project to 
build incorrectly. To correct this, please make sure that $(OutDir), 
$(TargetName) and $(TargetExt) property values match the value 
specified in %(Link.OutputFile).

1Link:
1 Creating library Release\libapr-1.lib and object 
Release\libapr-1.exp

1  libapr.vcxproj - E:\[delete]SVNTest\SVN\apr\.\Release\libapr.dll

Maybe these information ring a bell on ur side (atm it doesn't for me).


Hi Stefan,

OK, the plot thickens ... libapr.vcxproj
You only get the.vcxproj when using the IDE which uses the dsp files, 
not the .mak.


Bill found one today but it was in the Windows 9x build. This error 
message does not allude to this being a Win9x build.

http://svn.apache.org/r1687620

I can't find any others. I say search your libapr.dsp file for 
libapr.pdb but I don't think you will find it.


It looks like the compiler knows what it is told to do but instead is 
simply going to do what it wants to.



Hi Gregg,

already replied Bill per PM on his findings.

I guess u are right here. Somehow MSBuild 4.0 seems to ignore the 
passed /pdb parameter and rather sets the pdb-filename based on the 
$TargetName instead. The converted dsp-file doesn't explicitly set the 
TargetName (therefore using its default which is $ProjectName).
Modifying the vcxproj-file and setting TargetName to $(ProjectName)-1 
resolves the MSBuild warning and creates the correctly named pdb-file.


I don't know whether this suspicion of mine (bug in MSBuild 4.0) is 
true or not and I couldn't spot any reference on the web (and tbh I'm 
not familiar enough with the MSBuild internals to make a proper 
assumption here).


Given the current findings, I'm not sure whether you want to adjust 
the build setup to update the TargetName parameter and set it to the 
proper value. I'd argue

Re: [VOTE] Release Apache httpd 2.4.15 as GA

[Gregg Smith]

On 6/19/2015 9:50 AM, Jim Jagielski 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

VC9/12 and various Windows flavors.
Thanks for RMing

Re: SSLCertificateChainFile deprecation, still (was: svn commit: r1685371 - /httpd/httpd/branches/2.4.x/STATUS)

[Gregg Smith]

On 6/14/2015 2:54 AM, Yann Ylavic wrote:

On Sun, Jun 14, 2015 at 11:29 AM,gsm...@apache.org  wrote:

Author: gsmith
Date: Sun Jun 14 09:29:50 2015
New Revision: 1685371

URL: http://svn.apache.org/r1685371
Log:
-1 vote w/ comment

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=1685371r1=1685370r2=1685371view=diff
==
--- httpd/httpd/branches/2.4.x/STATUS (original)
+++ httpd/httpd/branches/2.4.x/STATUS Sun Jun 14 09:29:50 2015
@@ -207,6 +207,8 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
   2.4.x patch: 
http://people.apache.org/~ylavic/httpd-2.4.x-deprecated_SSLCertificateChainFile_once.patch
trunk works (modulo CHANGES, above is a review patch only)
   +1: ylavic, trawick
+ -1: gsmith, Tested, don't work! APLOG_INFO|APLOG_STARTUP will not work
+ together. Similar APLOG_* caveat as APLOG_TOCLIENT.

Indeed...
So, AIUI, it won't be logged unless httpd is started with -e info or more.
Isn't that finally what we want since [warn] seems to high?


Ok, yes that does work, this has been a day of learning.

However doing so I think the original intent is now lost which is to 
inform the user of SSLCertificateChainFile's deprecation. The 
unfortunate result of which was the hundreds/thousands of warnings 3 
times over on servers with many ssl hosts. At least I got it three times 
per host, but I only have a few. It also didn't take a -e warn to get it.


Now however should I want to follow up and use -e info, it's a game of 
what-a-mole cause it will only tell me the first place in my config it's 
at, not all of them. So essentially I would have to fix one, start again 
with -e to find the next. Let's assume I don't have search  replace or 
have included many conf files and do not have find in files at my disposal.


I think we can do both, not require a -e and simply inform the user 
(just once at startup) of SSLCertificateChainFile's deprecation and then 
give them list with -e info should they care to follow up on it.


I have reverted my -1 and will move out of the way. 2.4.14 is kaput with 
the chunk size regression so we have a small window.


As my day must end now, this is untested. But wouldn't this be a 
compromise to both? They will normally be gently informed (once) but -e 
info will inundated them with every line in every file they are using 
SSLCertificateChainFile in. In this case at lease they have requested it.


http://people.apache.org/~gsmith/proposal/sslcertificatechainfile_compromise.diff

Re: SSLCertificateChainFile deprecation, still (was: svn commit: r1685371 - /httpd/httpd/branches/2.4.x/STATUS)

[Gregg Smith]

On 6/14/2015 6:14 PM, Gregg Smith wrote:

On 6/14/2015 2:56 PM, Yann Ylavic wrote:

On Sun, Jun 14, 2015 at 1:31 PM, Gregg Smithg...@gknw.net  wrote:
http://people.apache.org/~gsmith/proposal/sslcertificatechainfile_compromise.diff 


I'm fine with this approach too.
We have to decide whether a single [warn] is acceptable or not since
it may still confuse startup monitors, which was a point raised in the
[Vote] thread.
I agree that the current patch proposed in STATUS is nearly the same
as not noticing the user since it requires -e info in the command-line
for anything to be visible, but I'm afraid any warning won't be
accepted now...


It's a lose/lose situation either way. I didn't pick up on the startup 
monitors part of the thread.


We are almost back to the way it was before the warning, I guess this 
is fine. No will know the better unless they go fishing for some other 
problem that may arise. At the very minimum it's something at least, 
should not make waves and i would bet everyone knows about it now 
unless 2.4.15 is their first.


If this is their first, probably ought to remove this in httpd-ssl.conf also

#   Server Certificate Chain:
#   Point SSLCertificateChainFile at a file containing the
#   concatenation of PEM encoded CA certificates which form the
#   certificate chain for the server certificate. Alternatively
#   the referenced file can be the same as SSLCertificateFile
#   when the CA certificates are directly appended to the server
#   certificate for convenience.
#SSLCertificateChainFile @rel_sysconfdir@/server-ca.crt

Re: SSLCertificateChainFile deprecation, still (was: svn commit: r1685371 - /httpd/httpd/branches/2.4.x/STATUS)

[Gregg Smith]

On 6/14/2015 2:56 PM, Yann Ylavic wrote:

On Sun, Jun 14, 2015 at 1:31 PM, Gregg Smithg...@gknw.net  wrote:

http://people.apache.org/~gsmith/proposal/sslcertificatechainfile_compromise.diff

I'm fine with this approach too.
We have to decide whether a single [warn] is acceptable or not since
it may still confuse startup monitors, which was a point raised in the
[Vote] thread.
I agree that the current patch proposed in STATUS is nearly the same
as not noticing the user since it requires -e info in the command-line
for anything to be visible, but I'm afraid any warning won't be
accepted now...


It's a lose/lose situation either way. I didn't pick up on the startup 
monitors part of the thread.


We are almost back to the way it was before the warning, I guess this is 
fine. No will know the better unless they go fishing for some other 
problem that may arise. At the very minimum it's something at least, 
should not make waves and i would bet everyone knows about it now unless 
2.4.15 is their first.


You have my vote, sorry for the trouble.

Re: mod_deflate was Re: [VOTE] Release Apache httpd 2.4.13 as GA

[Gregg Smith]

On 6/4/2015 10:01 PM, William A Rowe Jr wrote:

On Thu, Jun 4, 2015 at 10:47 PM, Gregg Smithg...@gknw.net  wrote:


This is new, not quite sure how I didn't see it a few weeks ago as it's 9
weeks old.
Who forgot to fill in the number?

mod_deflate.c(1283) : warning C4003: not enough actual parameters for
macro 'APLOGNO'


I just rechecked my compilation from near-trunk 6 hours ago, I don't see
this.

More background, please?  gcc or other compiler rev?  OS?  Revision?

It avoids a lot of needless speculation.


It's not a compiler thing, doesn't matter what OS. Sorry I didn't 
mention it's r1669555, my bad! You have the line number in the posted 
compiler output. However, it's pretty hard to miss as it's in the first 
stanza of the merge and practically hops in your lap.


http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/filters/mod_deflate.c?r1=1661845r2=1669555