You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Eric Covener <co...@gmail.com> on 2013/09/20 17:12:48 UTC
Re: [VOTE] Release Apache httpd 2.4.5 as GA
> I propose the following patch:
>
> http://people.apache.org/~rjung/patches/vhost-pr54948-part2.patch
>
> Caution: I did not really understand that code, but tracked what
> happened during digesting the broken config using additional log output.
> The original patch for PR54948 not only removed the unwanted internal
> duplicates but also dropped the 443 part from any ":80 :443" VirtualHost.
>
> Someone knowing this code better should confirm, whether my addition is
> correct or whether PR54948 should be fixed in a different way.
>
> IMHO the current 2.4.5 code is really broken and we should either
> release the code with r1485675 reverted or an additional fix on top.
>
> The config that was broken is our ASF www.apache.org config. Version
> 2.4.5 ignored the 443 part of most of the ":80 :443" vhosts, more
> precisely all except for the default vhost and the first internally
> processed one. Since the first processed one was the last declared one,
> which was originally meant as a fall through catch all, that vhost now
> handled all 443 traffic.
I applied this to trunk after running into an unrelated NVH issue and
sorting through some of the confusing structures again.
But I looked closer at the infra config, and I cannot simulate it
without also adding "listen 443 http" otherwise mod_ssl complains that
the <vh *:80 *:443> doesn't have a cert. Do you know this works on
www.a.o?
Re: [VOTE] Release Apache httpd 2.4.5 as GA
Posted by Eric Covener <co...@gmail.com>.
On Fri, Sep 20, 2013 at 2:18 PM, Rainer Jung <ra...@kippdata.de> wrote:
> Hi Eric,
>
> On 20.09.2013 17:12, Eric Covener wrote:
>>> I propose the following patch:
>>>
>>> http://people.apache.org/~rjung/patches/vhost-pr54948-part2.patch
>>>
>>> Caution: I did not really understand that code, but tracked what
>>> happened during digesting the broken config using additional log output.
>>> The original patch for PR54948 not only removed the unwanted internal
>>> duplicates but also dropped the 443 part from any ":80 :443" VirtualHost.
>>>
>>> Someone knowing this code better should confirm, whether my addition is
>>> correct or whether PR54948 should be fixed in a different way.
>>>
>>> IMHO the current 2.4.5 code is really broken and we should either
>>> release the code with r1485675 reverted or an additional fix on top.
>>>
>>> The config that was broken is our ASF www.apache.org config. Version
>>> 2.4.5 ignored the 443 part of most of the ":80 :443" vhosts, more
>>> precisely all except for the default vhost and the first internally
>>> processed one. Since the first processed one was the last declared one,
>>> which was originally meant as a fall through catch all, that vhost now
>>> handled all 443 traffic.
>>
>> I applied this to trunk after running into an unrelated NVH issue and
>> sorting through some of the confusing structures again.
>>
>> But I looked closer at the infra config, and I cannot simulate it
>> without also adding "listen 443 http" otherwise mod_ssl complains that
>> the <vh *:80 *:443> doesn't have a cert. Do you know this works on
>> www.a.o?
>
> I see only normal "Listen IP:Port" statements, some for port 80, others
> for 443.
>
> There are lots of vhost include files that use
>
> <VirtualHost *:80 *:443>
>
> but only one actually has SSL enabled:
>
> <VirtualHost _default_:443>
>
> And that one does carry a wildcard certificate.
>
> I haven't read the above thread yet again, but wasn't it about multiple
> ports? So any additional port like 80 and 81 should do to reproduce the
> problem. If that really helps you I can make up a minimal configuration,
> but probably you are after something else?
>
Thanks but no need for new config, was just curious if you knew how
the particular/unusual www.a.o config worked. The first go around, I
assumed the VH w/ 80 and 443 had SSL directives in it but no SSLEngine
which was somehow implicitly enabled due to the protocol of the
listener -- but my there are no SSL directives, and my httpd won't
even allow it to start up.
--
Eric Covener
covener@gmail.com
Re: [VOTE] Release Apache httpd 2.4.5 as GA
Posted by Rainer Jung <ra...@kippdata.de>.
Hi Eric,
On 20.09.2013 17:12, Eric Covener wrote:
>> I propose the following patch:
>>
>> http://people.apache.org/~rjung/patches/vhost-pr54948-part2.patch
>>
>> Caution: I did not really understand that code, but tracked what
>> happened during digesting the broken config using additional log output.
>> The original patch for PR54948 not only removed the unwanted internal
>> duplicates but also dropped the 443 part from any ":80 :443" VirtualHost.
>>
>> Someone knowing this code better should confirm, whether my addition is
>> correct or whether PR54948 should be fixed in a different way.
>>
>> IMHO the current 2.4.5 code is really broken and we should either
>> release the code with r1485675 reverted or an additional fix on top.
>>
>> The config that was broken is our ASF www.apache.org config. Version
>> 2.4.5 ignored the 443 part of most of the ":80 :443" vhosts, more
>> precisely all except for the default vhost and the first internally
>> processed one. Since the first processed one was the last declared one,
>> which was originally meant as a fall through catch all, that vhost now
>> handled all 443 traffic.
>
> I applied this to trunk after running into an unrelated NVH issue and
> sorting through some of the confusing structures again.
>
> But I looked closer at the infra config, and I cannot simulate it
> without also adding "listen 443 http" otherwise mod_ssl complains that
> the <vh *:80 *:443> doesn't have a cert. Do you know this works on
> www.a.o?
I see only normal "Listen IP:Port" statements, some for port 80, others
for 443.
There are lots of vhost include files that use
<VirtualHost *:80 *:443>
but only one actually has SSL enabled:
<VirtualHost _default_:443>
And that one does carry a wildcard certificate.
I haven't read the above thread yet again, but wasn't it about multiple
ports? So any additional port like 80 and 81 should do to reproduce the
problem. If that really helps you I can make up a minimal configuration,
but probably you are after something else?
Regards,
Rainer
--
kippdata
informationstechnologie GmbH Tel: 0228 98549 -0
Bornheimer Str. 33a Fax: 0228 98549 -50
53111 Bonn www.kippdata.de
HRB 8018 Amtsgericht Bonn / USt.-IdNr. DE 196 457 417
Geschäftsführer: Dr. Thomas Höfer, Rainer Jung, Sven Maurmann