Re: "Upgrade: h2" header for HTTP/1.1 via TLS (Bug 59311)

[Jacob Champion]

On 06/15/2016 01:32 PM, William A Rowe Jr wrote:

It seems to me that we -can- implement
Connection: Upgrade
Upgrade: h2
on a plaintext connection, which is simply shorthand for Upgrade:
TLS/1.x, HTTP/2
where the TLS connection *must* handshake with the ALPN token 'h2' (the 102
Switching Protocols would be followed by a TLS HELO), and that
restricted set
of TLS protocols and ciphers acceptable to the HTTP/2 protocol.


It may be *allowed* (I'm still mulling it over in my head; it seems to 
me to be a substantial stretching of the spirit of the Upgrade dance)... 
but I would seriously hope that httpd *doesn't* decide to do this. At 
least not without a really good client use case first. Additional 
fragmentation of the handshake types increases complexity and attack 
surface.


I am very curious about Roy's assertion (AIUI) that the 'HTTP/2.0' 
upgrade token is implicitly defined by the existence of RFC 7540. What 
are its semantics? Are they equivalent to those of the 'h2c' token?


(I understand that RFC 7230 *registers* all tokens of the form 
'HTTP/m.n'. That is different to me than saying, "If someone in the 
future creates an RFC called HTTPv4, all 'HTTP/4.x' tokens are 
automatically defined by that specification, whether they know it or not.")


--Jacob

Re: "Upgrade: h2" header for HTTP/1.1 via TLS (Bug 59311)

[William A Rowe Jr]

Rather than put statements into Roy's mouth... here are the relevant posts
which
were not disputed;

https://lists.w3.org/Archives/Public/ietf-http-wg/2016AprJun/0152.html
https://lists.w3.org/Archives/Public/ietf-http-wg/2016AprJun/0169.html

It seems to me that we -can- implement
Connection: Upgrade
Upgrade: h2
on a plaintext connection, which is simply shorthand for Upgrade: TLS/1.x,
HTTP/2
where the TLS connection *must* handshake with the ALPN token 'h2' (the 102
Switching Protocols would be followed by a TLS HELO), and that restricted
set
of TLS protocols and ciphers acceptable to the HTTP/2 protocol.

The advantage is plainly obvious, no need to tear down and start back up
some
new connection to transition to h2.



On Fri, Jun 10, 2016 at 9:22 AM, William A Rowe Jr 
wrote:

> On Fri, Jun 10, 2016 at 4:03 AM, Stefan Eissing <
> stefan.eiss...@greenbytes.de> wrote:
>
>> Withdrawn the proposal in r1747668 after reading the comment from Roy
>> again.
>>
>
> Let's look at what Roy said... that httpd's implementation of HTTP/1.1 may
> choose
> to honor a Connection-Upgrade request header of h2, or http/2, or any
> other values
> we choose, because we are bound by the HTTP/1.1 RFC, not some arbitrary
> choice
> by the HTTP/2 RFC. Wrong RFC to change HTTP/1.1 behavior, these headers are
> only to be used in conformance with
> https://tools.ietf.org/html/rfc7230#section-6.7
>
> So the http/1.1 Upgrade response header must mirror what the server will
> honor
> for the Connection: Upgrade  http/1.1 -> {something else}
> Upgrade request value.
>
> My initial response is still correct, *if* httpd is willing to honor
> Upgrade: h2
> or Upgrade: http/2 request header values, then it is appropriate to offer
> these
> in the response headers. And as Roy says, we *can* do so irrespective of
> any claims within https://tools.ietf.org/html/rfc7540#section-3.2 because
> that
> is not the binding specification during the http/1.1 phase of the request.
>
> https://tools.ietf.org/html/rfc7540#page-78 registered the h2c token for
> the
> Upgrade token, HTTP (including HTTP/2) was already registered. However,
> no token 'h2' is registered. That doesn't prevent us or others from
> sending
> and respecting other values, SSL/ was long considered valid, but I don't
> see where 'h2' should be used in the context of the 'Upgrade' header.
>
> http://www.iana.org/assignments/http-upgrade-tokens/http-upgrade-tokens.xhtml
>
> For right now, 'h2' should not be presented if 'h2' will not be honored,
> IMHO.
>

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

[William A Rowe Jr]

Good point.
On Jun 15, 2016 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 .
>

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: Module Development - Advice Needed

[Van Ulden, Joost (NRCan/RNCan)]

Thanks everyone for your input.

We have created a GitHub repo for the module work here: 
https://github.com/Maps4HTML/mod_mapml

We will continue to develop and support the servlet until the module has been 
developed, tested, and made available. Pursuing this as part of the core httpd 
package distribution is preferable, but we can approach this as an add-in 
module as well.

In the interim, we will engage via the users and module-dev lists until we have 
a proof-of-concept module built. That way we can focus the discussions 
appropriately.

Cheers,

Joost van Ulden


-Original Message-
From: Nick Kew [mailto:n...@apache.org] 
Sent: Friday, May 27, 2016 1:55 AM
To: dev@httpd.apache.org
Subject: Re: Module Development - Advice Needed

On Thu, 2016-05-26 at 22:44 +, Van Ulden, Joost (NRCan/RNCan) wrote:

> I approached a couple of folks at ApacheCon in Vancouver about some 
> work that I am involved with that would benefit from an httpd module.
> I am sending this message to the list to provide more information, and 
> to seek advice on how we should proceed.
> 
> We are developing a format we call “Map Markup Language”, or MapML.
> The objective of this format is to describe Web map semantics – that 
> is scale / zoom, projection, extent, features, styles, licenses, 
> legends in the context of a hypermedia media type that can be 
> manipulated / interacted with through the uniform interface alone.  We 
> would like to eventually register the format as text/mapml.

This is seriously interesting.  I need to take a look, and will be well pleased 
if I can find time to take an active interest.

> A Java servlet prototype for this functionality is available:

I have yet to look at that.  Would you plan the module and servlet to grow in 
parallel as alternative implementations, or each to take its own path?  
Presumably there is something to be gained with the two alternative 
implementations?

> We would like some advice on how to proceed with the development of a 
> module. For instance should we pursue this as a third-party module?
> Can we tap into the community for development assistance if we don’t 
> have the required skills in-house? Any advice would be appreciated.

You've had a couple of suggestions from Bill: I would agree that either github 
or the apache incubator make sense and are options worth considering (the 
latter could lead to it eventually becoming a sub-project of httpd itself).

I would think, let the servlet be your guide.  If it's thriving then you have a 
good model.  If not, you learn lessons from it.
Either way, thanks for posting to tell us about your project!

As Jacob points out, the modules-dev list is a good resource for technical 
help.  It's low-traffic, but still populated by a fair few people willing and 
able to help.

--
Nick Kew

RE: Module Development - Advice Needed

[Van Ulden, Joost (NRCan/RNCan)]

Thanks everyone for your input.

We have created a GitHub repo for the module work here: 
https://github.com/Maps4HTML/mod_mapml

We will continue to develop and support the servlet until the module has been 
developed, tested, and made available. Pursuing this as part of the core httpd 
package distribution is preferable, but we can approach this as an add-in 
module as well.

In the interim, we will engage via the users and module-dev lists until we have 
a proof-of-concept module built. That way we can focus the discussions 
appropriately.

Cheers,

Joost van Ulden


-Original Message-
From: Nick Kew [mailto:n...@apache.org] 
Sent: Friday, May 27, 2016 1:55 AM
To: dev@httpd.apache.org
Subject: Re: Module Development - Advice Needed

On Thu, 2016-05-26 at 22:44 +, Van Ulden, Joost (NRCan/RNCan) wrote:

> I approached a couple of folks at ApacheCon in Vancouver about some 
> work that I am involved with that would benefit from an httpd module.
> I am sending this message to the list to provide more information, and 
> to seek advice on how we should proceed.
> 
> We are developing a format we call “Map Markup Language”, or MapML.
> The objective of this format is to describe Web map semantics – that 
> is scale / zoom, projection, extent, features, styles, licenses, 
> legends in the context of a hypermedia media type that can be 
> manipulated / interacted with through the uniform interface alone.  We 
> would like to eventually register the format as text/mapml.

This is seriously interesting.  I need to take a look, and will be well pleased 
if I can find time to take an active interest.

> A Java servlet prototype for this functionality is available:

I have yet to look at that.  Would you plan the module and servlet to grow in 
parallel as alternative implementations, or each to take its own path?  
Presumably there is something to be gained with the two alternative 
implementations?

> We would like some advice on how to proceed with the development of a 
> module. For instance should we pursue this as a third-party module?
> Can we tap into the community for development assistance if we don’t 
> have the required skills in-house? Any advice would be appreciated.

You've had a couple of suggestions from Bill: I would agree that either github 
or the apache incubator make sense and are options worth considering (the 
latter could lead to it eventually becoming a sub-project of httpd itself).

I would think, let the servlet be your guide.  If it's thriving then you have a 
good model.  If not, you learn lessons from it.
Either way, thanks for posting to tell us about your project!

As Jacob points out, the modules-dev list is a good resource for technical 
help.  It's low-traffic, but still populated by a fair few people willing and 
able to help.

--
Nick Kew

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

[William A Rowe Jr]

Steffen, thanks for the confirmation about SPKI (although why Windows users
persist in using mod_php over the php-fcgi sapi is beyond me... sigh). Note
that
your hack only works when mod_php and those extensions are built with the
same clib as httpd.exe.

I am concerned that some of the functions for reading/writing certificate
CRL chains
may require this in mod_ssl.so as well. A quick review of
apr_crypto_openssl-1.dll
suggests that none of the functions we use require this stub.

It's also reassuring that others see the value of using this with all
flavors of VC,
and not simply the most problematic VS14/VS15 versions.

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.

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?



-- Forwarded message --
From: Steffen 
Date: Wed, Jun 15, 2016 at 4:39 AM
Subject: Re: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./
CHANGES support/ab.c
To: dev@httpd.apache.org


I do not understand your conclusion.

Background you find :  https://www.openssl.org/docs/faq.html#PROG2

Also Apachelounge includes applink shim in http.exe with all (VC10/11/14),
this is done in cooperation of the PHP dev's.

Quote:
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.

Steffen


On Wednesday 15/06/2016 at 03:33, William A Rowe Jr wrote:

Two quick observations...

Every time OpenSSL was compiled against a different CRT, whether is was a
release build of OpenSSL and a debug build of httpd/ab, or whether OpenSSL
was built under Visual Studio 2012 and httpd/ab was built against VS 2015,
this issue would occur without this patch.

Visual Studio 2015 only magnified or brought this quirk to light.

I'm curious, having seen reports of a Windows specific defect in local CRL
validation, whether this is also required in httpd.

Sadly, OpenSSL only looks for this symbol in the currently executing binary
(recall Win32 is two-level namespace)... we bind libssl/libcrypto to
libaprutil.dll and mod_ssl.so.  Exporting this from httpd.exe isn't
practical.

If that is the root of the other CRL failure observation, I'm not sure that
OpenSSL's hack is going to resolve it for our custom BIO implementation.

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:

Author: wrowe
Date: Tue Jun 14 20:37:52 2016
New Revision: 1748461

URL: http://svn.apache.org/viewvc?rev=1748461=rev
Log:
abs: Include OPENSSL_Applink when compiling on Windows, to resolve
failures under Visual Studio 2015 and other mismatched MSVCRT flavors.

PR: 59630
Submitted by: Jan Ehrhardt 


Modified:
httpd/httpd/branches/2.2.x/   (props changed)
httpd/httpd/branches/2.2.x/CHANGES
httpd/httpd/branches/2.2.x/support/ab.c

Propchange: httpd/httpd/branches/2.2.x/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Tue Jun 14 20:37:52 2016
@@ -1,2 +1,2 @@
 
/httpd/httpd/branches/2.4.x:138,159,1648845,1649003,1681034,1682929,1682939,1707123,1722573,1726087
-/httpd/httpd/trunk:290940,395552,417988,451572,501364,583817,583830,611483,630858,639005,639010,647395,657354,657459,660461,660566,664330,678761,680082,681190,682369,683626,685112,686805,686809,687099,687754,693120,693392,693727-693728,696006,697093,706318,707163,708902,711421,713575,719357,720250,729316-729317,729586,732414,732504,732816,732832,733127,733134,733218-733219,734710,743589,755190,756671,756675,756678,756683,757741,761329,763394,764239,768535,769809,771587,771610,776325,777042,777091,778438-778439,778531,778942,780648,780655,780692,780697,780699,785457,785661,790587,803704,819480,823536,823563,834378,835046,891282,900022,932791,942209,952823,953311,955966,979120,981084,992625,1026743,1031551,1040304,1040373,1058192,1070096,1082189,1082196,1090645,1172732,1200040,1200372,1200374,1213380,1222335,1223048,1231446,1244211,1294306,1299738,1300171,130,1308862,1327036,1327080,1328133,1328325-1328326,1345319,1348656,1349905,1352912,1363183,1363186,1366344,1367778,1368131,136
 

Re: svn commit: r1748327 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS server/config.c server/core.c server/main.c

[Jacob Champion]

On 06/14/2016 11:19 PM, Christophe JAILLET wrote:

this worse a doc update somewhere.
Is there a page where such parameters are described?
I've only found [1], but expected a more comprehensive list.


I wasn't able to find anything either, except for the -h output for 
httpd, which is still missing several -D parameters. Maybe there should 
be a new section added to the man page?


--Jacob

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?

[Jim Jagielski]

Thx!

I'll plan on T tomorrow w/ a release on Monday.

> On Jun 15, 2016, at 5:57 AM, Steffen  wrote:
> 
> 
> Running now 2.4.21-dev  pulled today (wednesday), exported revision 1748510.
> 
> 
> So far all good.
> 
> 
> 
> 
> 
> 
> On Wednesday 15/06/2016 at 01:11, 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 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  :
>>> 
>>> On Mon, Jun 13, 2016 at 1:59 PM, Gregg Smith  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?

[Steffen]

Running now 2.4.21-dev  pulled today (wednesday), exported revision 
1748510.



So far all good.






On Wednesday 15/06/2016 at 01:11, 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 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  
:


On Mon, Jun 13, 2016 at 1:59 PM, Gregg Smith  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: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c

[Steffen]

Re: svn commit: r1748327 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS server/config.c server/core.c server/main.c

[Christophe JAILLET]

Hi,

this worse a doc update somewhere.
Is there a page where such parameters are described?
I've only found [1], but expected a more comprehensive list.

Best regards,
CJ

[1] http://httpd.apache.org/docs/2.4/en/programs/httpd.html


Le 14/06/2016 à 01:08, minf...@apache.org a écrit :

Author: minfrin
Date: Mon Jun 13 23:08:08 2016
New Revision: 1748327

URL: http://svn.apache.org/viewvc?rev=1748327=rev
Log:
core: Add -DDUMP_INCLUDES configtest to show the Include tree.

  Example:

 Included configuration files:
   (*) .../conf/httpd.conf
 (517) .../conf/extra/proxy-html.conf
   (91) /dev/null

Submitted by: Jacob Champion 
Reviewed by: covener, gsmith, minfrin

Modified:
 httpd/httpd/branches/2.4.x/   (props changed)
 httpd/httpd/branches/2.4.x/CHANGES
 httpd/httpd/branches/2.4.x/STATUS
 httpd/httpd/branches/2.4.x/server/config.c
 httpd/httpd/branches/2.4.x/server/core.c
 httpd/httpd/branches/2.4.x/server/main.c