Time for 2.4.17 soonish?

[Jim Jagielski]

I'd like to propose that we think about a 2.4.17 release
within a coupla weeks and that we try to get http/2
support in for that release.

Re: Time for 2.4.17 soonish?

[Stefan Eissing]

+1

> Am 22.09.2015 um 21:49 schrieb Jim Jagielski :
> 
> I'd like to propose that we think about a 2.4.17 release
> within a coupla weeks and that we try to get http/2
> support in for that release.
> 

Re: svn move modules/http2 modules/h2 ?

[Jim Jagielski]

IMO, we should keep it where it is (modules/http2 to complement
modules/http) but change the configure to --enable-http2 (but
also allow --enable-h2 as well)... After all, we enable http/1
via --enable-http 

Re: svn move modules/http2 modules/h2 ?

[Jim Jagielski]

+1

> On Sep 22, 2015, at 1:01 PM, Gregg Smith  wrote:
> 
> 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: svn move modules/http2 modules/h2 ?

[Stefan Eissing]

That quickly went the wrong way... ;-)

> Am 22.09.2015 um 19:39 schrieb Greg Stein :
> 
> Yeah... if anything, rename to mod_http2.
> 
>> On Tue, Sep 22, 2015 at 12:01 PM, Gregg Smith  wrote:
>> 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: 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: svn move modules/http2 modules/h2 ?

[Greg Stein]

Yeah... if anything, rename to mod_http2.

On Tue, Sep 22, 2015 at 12:01 PM, Gregg Smith  wrote:

> 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: svn commit: r1704683 - /httpd/httpd/trunk/docs/manual/mod/mod_remoteip.xml

[Eric Covener]

I struggled with the phrasing here, any fine-tuning (or more) appreciated.

Does our default make sense considering the warning at the top of the
doc? Should we make people specify "RemoteIPTrustedProxy *" if they
don't want to restrict it?

On Tue, Sep 22, 2015 at 2:11 PM,   wrote:
> Author: covener
> Date: Tue Sep 22 18:11:35 2015
> New Revision: 1704683
>
> URL: http://svn.apache.org/viewvc?rev=1704683=rev
> Log:
> add warnings and emphasize the defaults for trusted non-internal proxies)
>
>
> Modified:
> httpd/httpd/trunk/docs/manual/mod/mod_remoteip.xml
>
> Modified: httpd/httpd/trunk/docs/manual/mod/mod_remoteip.xml
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_remoteip.xml?rev=1704683=1704682=1704683=diff
> ==
> --- httpd/httpd/trunk/docs/manual/mod/mod_remoteip.xml (original)
> +++ httpd/httpd/trunk/docs/manual/mod/mod_remoteip.xml Tue Sep 22 18:11:35 
> 2015
> @@ -113,9 +113,12 @@ via the request headers.
>  header-field header as the useragent IP address, or list
>  of intermediate useragent IP addresses, subject to further configuration
>  of the  module="mod_remoteip">RemoteIPInternalProxy and
> -RemoteIPTrustedProxy 
> directives.  Unless these
> -other directives are used, mod_remoteip will trust all
> -hosts presenting a  module="mod_remoteip">RemoteIPHeader IP value.
> +RemoteIPTrustedProxy 
> directives.
> +
> + Unless these other directives are used, 
> mod_remoteip
> +will trust all hosts presenting a non internal address in the
> +RemoteIPHeader header value.
> +
>
>  Internal (Load Balancer) Example
>  
> @@ -213,20 +216,26 @@ RemoteIPProxiesHeader X-Forwarded-By
>
>  
>  RemoteIPTrustedProxy
> -Declare client intranet IP addresses trusted to present the 
> RemoteIPHeader value
> +Restrict client IP addresses trusted to present the 
> RemoteIPHeader value
>  RemoteIPTrustedProxy 
> proxy-ip|proxy-ip/subnet|hostname 
> ...
>  server configvirtual 
> host
>
>  
> -The RemoteIPTrustedProxy 
> directive adds one
> -or more addresses (or address blocks) to trust as presenting a valid
> -RemoteIPHeader value of the useragent IP.  Unlike the
> -RemoteIPInternalProxy 
> directive, any intranet
> +The RemoteIPTrustedProxy
> +directive restricts which peer IP addresses (or address blocks) will be
> +trusted to present  a valid RemoteIPHeader value of the useragent IP.
> +
> + Unlike the  module="mod_remoteip">RemoteIPInternalProxy directive, any 
> intranet
>  or private IP address reported by such proxies, including the 10/8, 
> 172.16/12,
>  192.168/16, 169.254/16 and 127/8 blocks (or outside of the IPv6 public
>  2000::/3 block) are not trusted as the useragent IP, and are left in the
>  RemoteIPHeader header's 
> value.
>
> +By default, mod_remoteip will trust
> +all hosts presenting a non internal address in the
> +RemoteIPHeader header value.
> +
> +
>  Trusted (Load Balancer) Example
>  
>  RemoteIPHeader X-Forwarded-For
> @@ -239,7 +248,7 @@ RemoteIPTrustedProxy proxy.example.com
>
>  
>  RemoteIPTrustedProxyList
> -Declare client intranet IP addresses trusted to present the 
> RemoteIPHeader value
> +Restrict client IP addresses trusted to present the 
> RemoteIPHeader value
>  RemoteIPTrustedProxyList filename
>  server configvirtual 
> host
>
>
>



-- 
Eric Covener
cove...@gmail.com

RE: Time for 2.4.17 soonish?

[Lu, Yingqi]

Yann,

Thanks very much for bringing it up. We would love to see that SO_REUSEPORT 
patch being merged into the release version of the httpd. It has been a long 
time :)

Thanks,
Yingqi

-Original Message-
From: Yann Ylavic [mailto:ylavic@gmail.com] 
Sent: Tuesday, September 22, 2015 1:23 PM
To: dev@httpd.apache.org
Subject: Re: Time for 2.4.17 soonish?

+1, possibly with SO_REUSEPORT too.

On Tue, Sep 22, 2015 at 9:49 PM, Jim Jagielski  wrote:
> I'd like to propose that we think about a 2.4.17 release within a 
> coupla weeks and that we try to get http/2 support in for that 
> release.
>

Re: svn commit: r1703415 - in /httpd/test/framework/trunk/c-modules: authany/mod_authany.c test_session/mod_test_session.c

[William A Rowe Jr]

On Wed, Sep 16, 2015 at 10:08 AM, Jim Jagielski  wrote:

> All this is due to changes mode with the mainter-mode and
> which causes build stop error and stop for these kinds
> of warnings. These are simple 'squash warning' patches.


As Greg points out these are toxic and unacceptable, thanks to Yann for
reverting/truly correcting.

Bill

Re: svn commit: r1704683 - /httpd/httpd/trunk/docs/manual/mod/mod_remoteip.xml

[William A Rowe Jr]

I will try, I'm having trouble coming to terms with the idea because there
is no way
one would ever want private IP info from networks outside of their control
to be
used for access control.

If you require ip 127.0.0.1 for your monitoring app/mod_status for example,
this
suggestion completely destroys your ability to perform that.  Private IP
assignments
are just that, and their inclusion in this module were largely for bridged
private
environments where the administrator has control of both.

On Tue, Sep 22, 2015 at 1:13 PM, Eric Covener  wrote:

> I struggled with the phrasing here, any fine-tuning (or more) appreciated.
>
> Does our default make sense considering the warning at the top of the
> doc? Should we make people specify "RemoteIPTrustedProxy *" if they
> don't want to restrict it?
>
> On Tue, Sep 22, 2015 at 2:11 PM,   wrote:
> > Author: covener
> > Date: Tue Sep 22 18:11:35 2015
> > New Revision: 1704683
> >
> > URL: http://svn.apache.org/viewvc?rev=1704683=rev
> > Log:
> > add warnings and emphasize the defaults for trusted non-internal proxies)
> >
> >
> > Modified:
> > httpd/httpd/trunk/docs/manual/mod/mod_remoteip.xml
> >
> > Modified: httpd/httpd/trunk/docs/manual/mod/mod_remoteip.xml
> > URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_remoteip.xml?rev=1704683=1704682=1704683=diff
> >
> ==
> > --- httpd/httpd/trunk/docs/manual/mod/mod_remoteip.xml (original)
> > +++ httpd/httpd/trunk/docs/manual/mod/mod_remoteip.xml Tue Sep 22
> 18:11:35 2015
> > @@ -113,9 +113,12 @@ via the request headers.
> >  header-field header as the useragent IP address, or list
> >  of intermediate useragent IP addresses, subject to further
> configuration
> >  of the  module="mod_remoteip">RemoteIPInternalProxy and
> > -RemoteIPTrustedProxy
> directives.  Unless these
> > -other directives are used, mod_remoteip will trust
> all
> > -hosts presenting a  module="mod_remoteip">RemoteIPHeader IP value.
> > +RemoteIPTrustedProxy
> directives.
> > +
> > + Unless these other directives are used,
> mod_remoteip
> > +will trust all hosts presenting a non internal address in the
> > +RemoteIPHeader header
> value.
> > +
> >
> >  Internal (Load Balancer) Example
> >  
> > @@ -213,20 +216,26 @@ RemoteIPProxiesHeader X-Forwarded-By
> >
> >  
> >  RemoteIPTrustedProxy
> > -Declare client intranet IP addresses trusted to present
> the RemoteIPHeader value
> > +Restrict client IP addresses trusted to present the
> RemoteIPHeader value
> >  RemoteIPTrustedProxy
> proxy-ip|proxy-ip/subnet|hostname
> ...
> >  server configvirtual
> host
> >
> >  
> > -The  module="mod_remoteip">RemoteIPTrustedProxy directive adds one
> > -or more addresses (or address blocks) to trust as presenting a valid
> > -RemoteIPHeader value of the useragent IP.  Unlike the
> > -RemoteIPInternalProxy
> directive, any intranet
> > +The  module="mod_remoteip">RemoteIPTrustedProxy
> > +directive restricts which peer IP addresses (or address blocks)
> will be
> > +trusted to present  a valid RemoteIPHeader value of the useragent
> IP.
> > +
> > + Unlike the  module="mod_remoteip">RemoteIPInternalProxy directive, any
> intranet
> >  or private IP address reported by such proxies, including the 10/8,
> 172.16/12,
> >  192.168/16, 169.254/16 and 127/8 blocks (or outside of the IPv6
> public
> >  2000::/3 block) are not trusted as the useragent IP, and are left
> in the
> >  RemoteIPHeader
> header's value.
> >
> > +By default, mod_remoteip will
> trust
> > +all hosts presenting a non internal address in the
> > +RemoteIPHeader header
> value.
> > +
> > +
> >  Trusted (Load Balancer) Example
> >  
> >  RemoteIPHeader X-Forwarded-For
> > @@ -239,7 +248,7 @@ RemoteIPTrustedProxy proxy.example.com
> >
> >  
> >  RemoteIPTrustedProxyList
> > -Declare client intranet IP addresses trusted to present
> the RemoteIPHeader value
> > +Restrict client IP addresses trusted to present the
> RemoteIPHeader value
> >  RemoteIPTrustedProxyList filename
> >  server configvirtual
> host
> >
> >
> >
>
>
>
> --
> Eric Covener
> cove...@gmail.com
>

Re: svn commit: r1704683 - /httpd/httpd/trunk/docs/manual/mod/mod_remoteip.xml

[Eric Covener]

Maybe my followup is better phrased.  No issue with handling of internal IPs.

Currently, we act like RemoteIPTrustedProxy * by default (once they've
named the XFF header) and warn people they'd better restrict it.

On Tue, Sep 22, 2015 at 9:20 PM, William A Rowe Jr  wrote:
> I will try, I'm having trouble coming to terms with the idea because there
> is no way
> one would ever want private IP info from networks outside of their control
> to be
> used for access control.
>
> If you require ip 127.0.0.1 for your monitoring app/mod_status for example,
> this
> suggestion completely destroys your ability to perform that.  Private IP
> assignments
> are just that, and their inclusion in this module were largely for bridged
> private
> environments where the administrator has control of both.
>
> On Tue, Sep 22, 2015 at 1:13 PM, Eric Covener  wrote:
>>
>> I struggled with the phrasing here, any fine-tuning (or more) appreciated.
>>
>> Does our default make sense considering the warning at the top of the
>> doc? Should we make people specify "RemoteIPTrustedProxy *" if they
>> don't want to restrict it?
>>
>> On Tue, Sep 22, 2015 at 2:11 PM,   wrote:
>> > Author: covener
>> > Date: Tue Sep 22 18:11:35 2015
>> > New Revision: 1704683
>> >
>> > URL: http://svn.apache.org/viewvc?rev=1704683=rev
>> > Log:
>> > add warnings and emphasize the defaults for trusted non-internal
>> > proxies)
>> >
>> >
>> > Modified:
>> > httpd/httpd/trunk/docs/manual/mod/mod_remoteip.xml
>> >
>> > Modified: httpd/httpd/trunk/docs/manual/mod/mod_remoteip.xml
>> > URL:
>> > http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_remoteip.xml?rev=1704683=1704682=1704683=diff
>> >
>> > ==
>> > --- httpd/httpd/trunk/docs/manual/mod/mod_remoteip.xml (original)
>> > +++ httpd/httpd/trunk/docs/manual/mod/mod_remoteip.xml Tue Sep 22
>> > 18:11:35 2015
>> > @@ -113,9 +113,12 @@ via the request headers.
>> >  header-field header as the useragent IP address, or list
>> >  of intermediate useragent IP addresses, subject to further
>> > configuration
>> >  of the > > module="mod_remoteip">RemoteIPInternalProxy and
>> > -RemoteIPTrustedProxy
>> > directives.  Unless these
>> > -other directives are used, mod_remoteip will trust
>> > all
>> > -hosts presenting a > > module="mod_remoteip">RemoteIPHeader IP value.
>> > +RemoteIPTrustedProxy
>> > directives.
>> > +
>> > + Unless these other directives are used,
>> > mod_remoteip
>> > +will trust all hosts presenting a non internal address in the
>> > +RemoteIPHeader header
>> > value.
>> > +
>> >
>> >  Internal (Load Balancer) Example
>> >  
>> > @@ -213,20 +216,26 @@ RemoteIPProxiesHeader X-Forwarded-By
>> >
>> >  
>> >  RemoteIPTrustedProxy
>> > -Declare client intranet IP addresses trusted to present
>> > the RemoteIPHeader value
>> > +Restrict client IP addresses trusted to present the
>> > RemoteIPHeader value
>> >  RemoteIPTrustedProxy
>> > proxy-ip|proxy-ip/subnet|hostname
>> > ...
>> >  server configvirtual
>> > host
>> >
>> >  
>> > -The > > module="mod_remoteip">RemoteIPTrustedProxy directive adds one
>> > -or more addresses (or address blocks) to trust as presenting a
>> > valid
>> > -RemoteIPHeader value of the useragent IP.  Unlike the
>> > -RemoteIPInternalProxy
>> > directive, any intranet
>> > +The > > module="mod_remoteip">RemoteIPTrustedProxy
>> > +directive restricts which peer IP addresses (or address blocks)
>> > will be
>> > +trusted to present  a valid RemoteIPHeader value of the useragent
>> > IP.
>> > +
>> > + Unlike the > > module="mod_remoteip">RemoteIPInternalProxy directive, any
>> > intranet
>> >  or private IP address reported by such proxies, including the 10/8,
>> > 172.16/12,
>> >  192.168/16, 169.254/16 and 127/8 blocks (or outside of the IPv6
>> > public
>> >  2000::/3 block) are not trusted as the useragent IP, and are left
>> > in the
>> >  RemoteIPHeader
>> > header's value.
>> >
>> > +By default, mod_remoteip will
>> > trust
>> > +all hosts presenting a non internal address in the
>> > +RemoteIPHeader header
>> > value.
>> > +
>> > +
>> >  Trusted (Load Balancer) Example
>> >  
>> >  RemoteIPHeader X-Forwarded-For
>> > @@ -239,7 +248,7 @@ RemoteIPTrustedProxy proxy.example.com
>> >
>> >  
>> >  RemoteIPTrustedProxyList
>> > -Declare client intranet IP addresses trusted to present
>> > the RemoteIPHeader value
>> > +Restrict client IP addresses trusted to present the
>> > RemoteIPHeader value
>> >  RemoteIPTrustedProxyList filename
>> >  server configvirtual
>> > host
>> >
>> >
>> >
>>
>>
>>
>> --
>> Eric Covener
>> cove...@gmail.com
>
>



-- 
Eric Covener
cove...@gmail.com

Re: Time for 2.4.17 soonish?

[William A Rowe Jr]

+1 to picking this up now-ish and letting it run through the paces while we
are completing other things.

On Tue, Sep 22, 2015 at 3:23 PM, Yann Ylavic  wrote:

> +1, possibly with SO_REUSEPORT too.
>
> On Tue, Sep 22, 2015 at 9:49 PM, Jim Jagielski  wrote:
> > I'd like to propose that we think about a 2.4.17 release
> > within a coupla weeks and that we try to get http/2
> > support in for that release.
> >
>

Re: Disable SSLv3 by default

[William A Rowe Jr]

On Sat, Sep 19, 2015 at 4:05 AM, Kaspar Brand 
wrote:

> On 17.10.2014 19:25, Kaspar Brand wrote:
> > On 17.10.2014 12:02, Takashi Sato wrote:
> >> SSLv3 is now insecure (CVE-2014-3566, POODLE)
> >> Let's disable SSLv3 by default, at least trunk.
> >>
> >> SSLProtocol default is "all".
> >> 
> >> "all" means "a shortcut for ``+SSLv3 +TLSv1'' or - when using OpenSSL
> >> 1.0.1 and later - ``+SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2, respectively."
> >>
> >> Should we remove SSLv3 from "all" ?
> >
> > From a semantic point of view, I wouldn't do that. As long as we still
> > allow SSLv3 to be used, "all" should really mean "all protocols which
> > can be enabled in mod_ssl".
> >
> > I'm fine with changing the hardcoded default (in ssl_engine_config.c) to
> > SSL_PROTOCOL_ALL & ~SSL_PROTOCOL_SSLV3, though.
>
> For the record: this is part of r1703952 which I just committed to trunk
> (and will propose for backporting to 2.4 shortly, unless there are
> objections).
>
> > The other option would be to drop SSLv3 support completely, like we
> > currently do for SSLv2 in ssl_engine_init.c:ssl_init_ctx_protocol(). In
> > this case, "all" would no longer include SSLv3, of course.
>
> This is left as a next step, which I consider appropriate for trunk, at
> least.
>

Trunk, yes.  POLS says no, not 2.4, no matter how 'clean' that solution
seems.

You cannot break users migrating across a subversion bump.

You are welcome to scream at them in their error log that an ill-advised
protocol
has been requested, as long as it is non-fatal.

Re: svn move modules/http2 modules/h2 ?

[Yann Ylavic]

On Tue, Sep 22, 2015 at 9:52 PM, Jim Jagielski  wrote:
> IMO, we should keep it where it is (modules/http2 to complement
> modules/http) but change the configure to --enable-http2 (but
> also allow --enable-h2 as well)... After all, we enable http/1
> via --enable-http

I'm fine with this too, +1

Re: Time for 2.4.17 soonish?

[Yann Ylavic]

+1, possibly with SO_REUSEPORT too.

On Tue, Sep 22, 2015 at 9:49 PM, Jim Jagielski  wrote:
> I'd like to propose that we think about a 2.4.17 release
> within a coupla weeks and that we try to get http/2
> support in for that release.
>

Re: svn commit: r1704683 - /httpd/httpd/trunk/docs/manual/mod/mod_remoteip.xml

[William A Rowe Jr]

On Tue, Sep 22, 2015 at 8:48 PM, Eric Covener  wrote:

> Maybe my followup is better phrased.  No issue with handling of internal
> IPs.
>
> Currently, we act like RemoteIPTrustedProxy * by default (once they've
> named the XFF header) and warn people they'd better restrict it.
>

I agree that was not the original design and we should address it with a fix
rather than a docs fix, IMHO.  'Trusted' is the exception, not the general
case.

Re: svn move modules/http2 modules/h2 ?

[William A Rowe Jr]

+1 - mostly because --enable-http2 is easier to grok than --enable-h2, not
because I object to the old name :)
On Sep 22, 2015 12:39, "Greg Stein"  wrote:

> Yeah... if anything, rename to mod_http2.
>
> On Tue, Sep 22, 2015 at 12:01 PM, Gregg Smith  wrote:
>
>> 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
>>>
>>>
>>>
>>>
>>
>

mod_h2 – browsers getting confused

[Steffen]

Apachelounge made the branches/2.4.17-protocols-http2 binary available.

Issue reported: see https://www.apachelounge.com/viewtopic.php?p=31720

The poster there is referring to 
https://http2.github.io/http2-spec/#rfc.section.9.1.1


Steffen

mod_h2 – browsers getting confused

[Steffen]

Apachelounge made the binary available.

Issue reported: see https://www.apachelounge.com/viewtopic.php?p=31720#31720

The poster there is referring to 
https://http2.github.io/http2-spec/#rfc.section.9.1.1

Steffen

Re: connection reuse and ssl renegotiation

[Yann Ylavic]

On Tue, Sep 22, 2015 at 1:24 PM, Stefan Eissing
 wrote:
>
> SSL renegotiation is forbidden in HTTP/2, exactly due to concurrency issues.

Certainly a concurrency between each one's privacy and every one's
data in the same stream :)
Also, let servers trust the security of the client/proxy side...

> There is a debate currently on the http-wg mailing list, what to do about it, 
> especially for sites that use client certificates.

They should probably forbid client certificates too :p

(BTW, could you provide some links please?)

>
> As Apache httpd, we can at the moment only advise server administrators to 
> not enable HTTP/2 for servers/vhosts that make use of renegotiations.

How can the server know which request a client will issue next on the
same connection, same vhost? same path?
That would be a warning about using multiple vhosts with different SSL
parameters/certificates/... in httpd.conf.

> We should probably log an error when ap_get_protocol() != "http/1.1", when 
> renegotiation is attempted. Anyone know the best place to put that?

That's probably in ssl_hook_Access() when renegotiate &&
!renegotiate_quick => before we SSL_do_handshake().

>
> ssl_hook_Access() seems the renegotiation monster. Not sure if I want to 
> stick my fingers in there. But this seems to be the place to check the 
> protocol and make a log error (at least)? Or do we make a 
> connection_param_renegotiate hook that can stop renegotiation and set the 
> proper response on the request?

I think we should add more checks here about the current-server's
parameters vs the handshake-server's ones.
Is the handshaken protocol compatible with the current server's ones
(SSL_METHOD)?
Do the current-server's certificate's SN/SAN(s) include the requested Host?
Are the current's and handshake's SSLVerify equal, with the same CA[DN]s?
...???

Otherwise (or if a renegotiation is required in HTTP/2), bail out with 421.
This should work whenever the parameters/certificates are
shared/compatible between vhosts, putting the bargain at the admin.

Regards,
Yann.

connection reuse and ssl renegotiation

[Stefan Eissing]

Just an update on this topic:

We currently allow only connection reuse for the server/vhost that was selected 
by the SNI, thanks to the patch by Yann.

However, the problem is deeper than I originally thought: SSL renegotiation is 
forbidden in HTTP/2, exactly due to concurrency issues. There is a debate 
currently on the http-wg mailing list, what to do about it, especially for 
sites that use client certificates.

As Apache httpd, we can at the moment only advise server administrators to not 
enable HTTP/2 for servers/vhosts that make use of renegotiations. We should 
probably log an error when ap_get_protocol() != "http/1.1", when renegotiation 
is attempted. Anyone know the best place to put that?

ssl_hook_Access() seems the renegotiation monster. Not sure if I want to stick 
my fingers in there. But this seems to be the place to check the protocol and 
make a log error (at least)? Or do we make a connection_param_renegotiate hook 
that can stop renegotiation and set the proper response on the request?

//Stefan

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

Re: 2.4.17-protocols-http2 :: Restarting

[Steffen]

Update, running a few days.

Once in a few hours I see crashes.

With no-ssl and no_mod_h2 crash in libapr-1.dll

With ssl and mod_h2 crash in mod_h2.so

With mod_h2  see till now a few in the log:
[h2:warn] [pid 8980:tid 2740] (70015)Could not find specified socket in poll 
list.: [client 93.55.181.18:51564] AH02953: h2_mplx(112): stream for 
response 57


For http back to 2.4.16
For https and mod-h2 I keep it running.for now.

Steffen


From: Steffen
Sent: Monday, September 21, 2015 11:05 AM
To: Apache Devel List
Subject: Re: 2.4.17-protocols-http2 :: Restarting

About the huge number of warnings

[h2:warn] [pid 2036:tid 4008] (OS 10060)A connection attempt failed because 
the connected party did not properly respond after a period of time, or 
established connection failed because connected host has failed to respond. 
: [client 84.105.35.206:58278] AH02950: h2_session(124): error reading, 
terminating


Same  with no mod_h2, only ssl:info, mod_h2 has warn.

[ssl:info] [pid 4880:tid 1404] (OS 10060)A connection attempt failed because 
the connected party did not properly respond after a period of time, or 
established connection failed because connected host has failed to respond. 
: [client 211.23.119.218:43915] AH01991: SSL input filter read failed.


Long way back I discussed this on the list.

Steffen

From: Steffen
Sent: Monday, September 21, 2015 9:27 AM
To: Apache Devel List
Subject: 2.4.17-protocols-http2 :: Restarting

Running live now for almost two days, see 
https://www.apachelounge.com/viewtopic.php?p=31674


Was running fine, expect the log is filled with mod_h2 warnings (see below)
Suddenly after a few hours, it was starting all over and over, 105 times.
And running fine for a few hours without restarting.

Looks like a (bad) client is causing it.

Now I disabled mod_h2, to see if that is fine.

[mpm_winnt:notice] [pid 1644:tid 16] AH00428: Parent: child process 2036 
exited with status 3221225477 -- Restarting.


Windows says: Faulting module name: mod_h2.so, version: 2.4.17.

Log is filled (over 2000) with:

[h2:warn] [pid 2036:tid 4008] (OS 10060)A connection attempt failed because 
the connected party did not properly respond after a period of time, or 
established connection failed because connected host has failed to respond. 
: [client 84.105.35.206:58278] AH02950: h2_session(124): error reading, 
terminating


Few other errors/warning:

[h2:warn] [pid 2036:tid 4020] (70015)Could not find specified socket in poll 
list.: [client 90.21.243.213:57391] AH02953: h2_mplx(126): stream for 
response 49


[h2:error] [pid 3300:tid 2832] (OS 10053)An established connection was 
aborted by the software in your host machine.  : [client 
202.183.129.112:47902] AH02925: h2_stream(116-35): failed send_data_cb


[h2:error] [pid 3300:tid 2856] (OS 10054)An existing connection was forcibly 
closed by the remote host.  : [client 177.41.118.92:52990] AH02925: 
h2_stream(123-29): failed send_data_cb


Logs (level notice) attached.

Steffen 

R: Re: graceful child process exit

[massimo.man...@alice.it]

>Messaggio originale
>Da: sor...@gmail.com
>Data: 21-set-2015 9.22

>A: 
>Ogg: Re: graceful child process exit
>
>On 2015-09-21 00:45, Massimo 
Manghi wrote:
>
>Have a look at apr_pool_cleanup_register.
>
>I don't have 
pleasant memories with process pools. The problem is that 
>sometimes apache 
children take a long time to exit. When this happens 
>then the parent sends 
them signals in order to stop them, the signals 
>becoming progressively 
stronger (first sigterm, then sigkill if I 
>remember correctly). I do not 
remember the details, but I've been 
>getting segfaults at process exit, so I'm 
steering clear of process 
>pools since.
>
>Have a look if the conf pool is 
what you'd need. It is cleaned up every 
>time the apache configuration is 
reloaded (the parent apache process 
>stays alive, the apache worker children 
are stopped and a new generation 
>of apache children is created). You can use 
the second callback of the 
>apr_pool_cleanup_register to clean up things in 
the children.
>
>The difference between the conf pool and the process pool is 
the 
>following: the process pool is passed to the post_config and child_init 

>callbacks. The conf pool is not passed to child_init. So, in order to 

>initialise things in the conf_pool you'll need to set a callback in the 

>post_config hook. The post_config hook is executed as root in the parent 

>process, before it forks a new generation of children, every time the 
>apache 
configuration is reread (after each apache2ctl graceful). The 
>child_init hook 
is executed in the apache child every time the child 
>process is created and 
it executes without root privileges.
>
>
>Sorin
>

Thank you Sorin for the 
answer, sorry I'm at a conference and I can't answer with my apache.org 
identity. I don't think this message will get to the list unless someone will 
be so kind and gentle to approve it after it has been moderated.

The problem 
is that we have to implement a way to safely call 'exit' ourselves the way the 
procedures clean_child_exit does from within the MPM module. These procedures 
slightly differ between prefork and worker MPM and are private to the code of 
the MPM, so does a public API exists for that? 

clean_child_exit destroys the 
pChild pool in the first place and this in turn runs our cleanup procedure (we 
already have one set up) but it does other stuff that I imagine are vital for 
the web server ecosistem.
'
 -- Massimo

svn move modules/http2 modules/h2 ?

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

Re: svn move modules/http2 modules/h2 ?

[Stefan Eissing]

+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