2.4.27

classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

2.4.27

Jim Jagielski
Anyone opposed to a quick T&R and release of 2.4.27 within
the next week?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2.4.27

Stefan Eissing
> Am 03.07.2017 um 13:33 schrieb Jim Jagielski <[hidden email]>:
>
> Anyone opposed to a quick T&R and release of 2.4.27 within
> the next week?

+1

(read: all for it to happen)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2.4.27

Eric Covener
On Mon, Jul 3, 2017 at 7:34 AM, Stefan Eissing
<[hidden email]> wrote:
> +1
>
> (read: all for it to happen)


+1
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2.4.27

William A Rowe Jr
In reply to this post by Jim Jagielski
+1

On Jul 3, 2017 6:33 AM, "Jim Jagielski" <[hidden email]> wrote:
Anyone opposed to a quick T&R and release of 2.4.27 within
the next week?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2.4.27

Christian Folini-2
In reply to this post by Jim Jagielski
On Mon, Jul 03, 2017 at 07:33:01AM -0400, Jim Jagielski wrote:
> Anyone opposed to a quick T&R and release of 2.4.27 within
> the next week?

Will this be a release primarily addressing the open fast cgi regression
or are the additional security concerns with 2.4.26?

A quick note would help with the holiday schedule.

Regards,

Christian Folini

--
Christian Folini - <[hidden email]>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2.4.27

Jacob Champion-2
In reply to this post by Eric Covener
On 07/03/2017 04:45 AM, Eric Covener wrote:
> +1

+1

--Jacob

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2.4.27

Jim Jagielski
In reply to this post by Christian Folini-2
These are just the fixes/regressions noted in CHANGES:

Changes with Apache 2.4.27

  *) mod_lua: Improve compatibility with Lua 5.1, 5.2 and 5.3.
     PR58188, PR60831, PR61245. [Rainer Jung]
 
  *) mod_http2: disable and give warning when mpm_prefork is encountered. The server will
     continue to work, but HTTP/2 will no longer be negotiated. [Stefan Eissing]
 
  *) Allow single-char field names inadvertantly disallowed in 2.4.25.
     PR 61220. [Yann Ylavic]

  *) htpasswd / htdigest: Do not apply the strict permissions of the temporary
     passwd file to a possibly existing passwd file. PR 61240. [Ruediger Pluem]

  *) mod_proxy_fcgi: Revert to 2.4.20 FCGI behavior for the default
     ProxyFCGIBackendType, fixing a regression with PHP-FPM. PR 61202.
     [Jacob Champion, Jim Jagielski]

  *) core: Avoid duplicate HEAD in Allow header.
     This is a regression in 2.4.24 (unreleased), 2.4.25 and 2.4.26.
     PR 61207. [Christophe Jaillet]

> On Jul 3, 2017, at 1:39 PM, Christian Folini <[hidden email]> wrote:
>
> On Mon, Jul 03, 2017 at 07:33:01AM -0400, Jim Jagielski wrote:
>> Anyone opposed to a quick T&R and release of 2.4.27 within
>> the next week?
>
> Will this be a release primarily addressing the open fast cgi regression
> or are the additional security concerns with 2.4.26?
>
> A quick note would help with the holiday schedule.
>
> Regards,
>
> Christian Folini
>
> --
> Christian Folini - <[hidden email]>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2.4.27

Christian Folini-2
Thank you Jim.

On Wed, Jul 05, 2017 at 12:48:48PM -0400, Jim Jagielski wrote:

> These are just the fixes/regressions noted in CHANGES:
>
> Changes with Apache 2.4.27
>
>   *) mod_lua: Improve compatibility with Lua 5.1, 5.2 and 5.3.
>      PR58188, PR60831, PR61245. [Rainer Jung]
>  
>   *) mod_http2: disable and give warning when mpm_prefork is encountered. The server will
>      continue to work, but HTTP/2 will no longer be negotiated. [Stefan Eissing]
>  
>   *) Allow single-char field names inadvertantly disallowed in 2.4.25.
>      PR 61220. [Yann Ylavic]
>
>   *) htpasswd / htdigest: Do not apply the strict permissions of the temporary
>      passwd file to a possibly existing passwd file. PR 61240. [Ruediger Pluem]
>
>   *) mod_proxy_fcgi: Revert to 2.4.20 FCGI behavior for the default
>      ProxyFCGIBackendType, fixing a regression with PHP-FPM. PR 61202.
>      [Jacob Champion, Jim Jagielski]
>
>   *) core: Avoid duplicate HEAD in Allow header.
>      This is a regression in 2.4.24 (unreleased), 2.4.25 and 2.4.26.
>      PR 61207. [Christophe Jaillet]
>
> > On Jul 3, 2017, at 1:39 PM, Christian Folini <[hidden email]> wrote:
> >
> > On Mon, Jul 03, 2017 at 07:33:01AM -0400, Jim Jagielski wrote:
> >> Anyone opposed to a quick T&R and release of 2.4.27 within
> >> the next week?
> >
> > Will this be a release primarily addressing the open fast cgi regression
> > or are the additional security concerns with 2.4.26?
> >
> > A quick note would help with the holiday schedule.
> >
> > Regards,
> >
> > Christian Folini
> >
> > --
> > Christian Folini - <[hidden email]>

--
Christian Folini - <[hidden email]>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: 2.4.27

Bert Huijben
In reply to this post by Jim Jagielski


> -----Original Message-----
> From: Jim Jagielski [mailto:[hidden email]]
> Sent: woensdag 5 juli 2017 18:49
> To: [hidden email]
> Subject: Re: 2.4.27
>
> These are just the fixes/regressions noted in CHANGES:
>
> Changes with Apache 2.4.27
>
>   *) mod_lua: Improve compatibility with Lua 5.1, 5.2 and 5.3.
>      PR58188, PR60831, PR61245. [Rainer Jung]
>
>   *) mod_http2: disable and give warning when mpm_prefork is
> encountered. The server will
>      continue to work, but HTTP/2 will no longer be negotiated. [Stefan
Eissing]

Can somebody point me to the reasoning behind this?

I have this configuration on FreeBSD with older Httpd versions, and it works
just fine for my limited load.

Switching to a different model will require compiling more ports myself as
the FreeBSD packaging system is optimized for this model.


I do understand that there is a better mapping of http/2 streams with the
more modern MPMs, but there must be a reason that it worked and no longer
can be supported in the future. I assume this reason is already documented
somewhere...

Thanks,

        Bert


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2.4.27

Eric Covener
On Thu, Jul 6, 2017 at 10:55 AM, Bert Huijben <[hidden email]> wrote:

>>   *) mod_http2: disable and give warning when mpm_prefork is
>> encountered. The server will
>>      continue to work, but HTTP/2 will no longer be negotiated. [Stefan
> Eissing]
>
> Can somebody point me to the reasoning behind this?
>
> I have this configuration on FreeBSD with older Httpd versions, and it works
> just fine for my limited load.
>
> Switching to a different model will require compiling more ports myself as
> the FreeBSD packaging system is optimized for this model.
>
>
> I do understand that there is a better mapping of http/2 streams with the
> more modern MPMs, but there must be a reason that it worked and no longer
> can be supported in the future. I assume this reason is already documented
> somewhere...


IIUC, the default in the last release (and earlier?) started creating
H2 worker threads in each prefork process.
Generally, prefork is still used to run non-threadsafe plugins.
If we don't create multiple threads, the H2 responses are done serially.

Maybe it needs a backdoor to allow being re-enabled?

--
Eric Covener
[hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2.4.27

Stefan Eissing
In reply to this post by Bert Huijben
Hej,

I tried to gather some discussion about this. Should have polled this mailing list. You can read most of it here: https://github.com/icing/mod_h2/issues/142

tl;dr

I had several reports in the past of people being disappointed about h2 performance, only to learn they were on prefork. Which means every request is processed serially (with static files being an exception, as long as no filters prevent this).

In 2.4.26 I changed the (undocumented) default from 1 to 4 h2 workers, which brought us to the issue I linked. The easy fix is 'H2MaxWorkers 1' in the config and you have the pre-2.4.26 behaviour.

Regardless of the discussion if the change in 2.4.26 was reasonable or not: it is not possible to map the prefork single-thread requirement on to HTTP/2. Not going to work. One long running request, one websocket opened, and your browser will stall.

This is not a bug, it is the collision of the processing models.

So, I think disabling it prevent user from shooting themselves in the foot. If you are on prefork, you'd want the 6 parallel HTTP/1.1 connections, not h2.

Does this make sense?

Cheers,

Stefan

PS. Yes, I know that one /could/ make parallel processes work in prefork by placing the h2 dispatching in a parent process. If someone wants to implement that, be my guest.


> Am 06.07.2017 um 16:55 schrieb Bert Huijben <[hidden email]>:
>
>
>
>> -----Original Message-----
>> From: Jim Jagielski [mailto:[hidden email]]
>> Sent: woensdag 5 juli 2017 18:49
>> To: [hidden email]
>> Subject: Re: 2.4.27
>>
>> These are just the fixes/regressions noted in CHANGES:
>>
>> Changes with Apache 2.4.27
>>
>>  *) mod_lua: Improve compatibility with Lua 5.1, 5.2 and 5.3.
>>     PR58188, PR60831, PR61245. [Rainer Jung]
>>
>>  *) mod_http2: disable and give warning when mpm_prefork is
>> encountered. The server will
>>     continue to work, but HTTP/2 will no longer be negotiated. [Stefan
> Eissing]
>
> Can somebody point me to the reasoning behind this?
>
> I have this configuration on FreeBSD with older Httpd versions, and it works
> just fine for my limited load.
>
> Switching to a different model will require compiling more ports myself as
> the FreeBSD packaging system is optimized for this model.
>
>
> I do understand that there is a better mapping of http/2 streams with the
> more modern MPMs, but there must be a reason that it worked and no longer
> can be supported in the future. I assume this reason is already documented
> somewhere...
>
> Thanks,
>
> Bert
>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2.4.27

Stefan Eissing
Correction: websockets are not defined over h2. To make a more "real life" scenario:

One example is a long polling request by a javascript component. During the long poll, the browser will not get other responses.

More esoteric: when content filters (brotli, gzip) are in place, compression happens in the h2 worker thread. If one PUSHes such a resource, clients sometimes use h2 flow control to delay the sending of a response. This would deadlock the connection in a prefork model.

These are complications not easily debugged or reproducible.

> Am 06.07.2017 um 17:15 schrieb Stefan Eissing <[hidden email]>:
>
> Hej,
>
> I tried to gather some discussion about this. Should have polled this mailing list. You can read most of it here: https://github.com/icing/mod_h2/issues/142
>
> tl;dr
>
> I had several reports in the past of people being disappointed about h2 performance, only to learn they were on prefork. Which means every request is processed serially (with static files being an exception, as long as no filters prevent this).
>
> In 2.4.26 I changed the (undocumented) default from 1 to 4 h2 workers, which brought us to the issue I linked. The easy fix is 'H2MaxWorkers 1' in the config and you have the pre-2.4.26 behaviour.
>
> Regardless of the discussion if the change in 2.4.26 was reasonable or not: it is not possible to map the prefork single-thread requirement on to HTTP/2. Not going to work. One long running request, one websocket opened, and your browser will stall.
>
> This is not a bug, it is the collision of the processing models.
>
> So, I think disabling it prevent user from shooting themselves in the foot. If you are on prefork, you'd want the 6 parallel HTTP/1.1 connections, not h2.
>
> Does this make sense?
>
> Cheers,
>
> Stefan
>
> PS. Yes, I know that one /could/ make parallel processes work in prefork by placing the h2 dispatching in a parent process. If someone wants to implement that, be my guest.
>
>
>> Am 06.07.2017 um 16:55 schrieb Bert Huijben <[hidden email]>:
>>
>>
>>
>>> -----Original Message-----
>>> From: Jim Jagielski [mailto:[hidden email]]
>>> Sent: woensdag 5 juli 2017 18:49
>>> To: [hidden email]
>>> Subject: Re: 2.4.27
>>>
>>> These are just the fixes/regressions noted in CHANGES:
>>>
>>> Changes with Apache 2.4.27
>>>
>>> *) mod_lua: Improve compatibility with Lua 5.1, 5.2 and 5.3.
>>>    PR58188, PR60831, PR61245. [Rainer Jung]
>>>
>>> *) mod_http2: disable and give warning when mpm_prefork is
>>> encountered. The server will
>>>    continue to work, but HTTP/2 will no longer be negotiated. [Stefan
>> Eissing]
>>
>> Can somebody point me to the reasoning behind this?
>>
>> I have this configuration on FreeBSD with older Httpd versions, and it works
>> just fine for my limited load.
>>
>> Switching to a different model will require compiling more ports myself as
>> the FreeBSD packaging system is optimized for this model.
>>
>>
>> I do understand that there is a better mapping of http/2 streams with the
>> more modern MPMs, but there must be a reason that it worked and no longer
>> can be supported in the future. I assume this reason is already documented
>> somewhere...
>>
>> Thanks,
>>
>> Bert
>>
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2.4.27

Jim Jagielski
In reply to this post by Stefan Eissing

> On Jul 6, 2017, at 11:15 AM, Stefan Eissing <[hidden email]> wrote:
>
> Hej,
>
> I tried to gather some discussion about this. Should have polled this mailing list. You can read most of it here: https://github.com/icing/mod_h2/issues/142
>
> tl;dr
>
> I had several reports in the past of people being disappointed about h2 performance, only to learn they were on prefork. Which means every request is processed serially (with static files being an exception, as long as no filters prevent this).
>
> In 2.4.26 I changed the (undocumented) default from 1 to 4 h2 workers, which brought us to the issue I linked. The easy fix is 'H2MaxWorkers 1' in the config and you have the pre-2.4.26 behaviour.
>
> Regardless of the discussion if the change in 2.4.26 was reasonable or not: it is not possible to map the prefork single-thread requirement on to HTTP/2. Not going to work. One long running request, one websocket opened, and your browser will stall.
>
> This is not a bug, it is the collision of the processing models.
>
> So, I think disabling it prevent user from shooting themselves in the foot. If you are on prefork, you'd want the 6 parallel HTTP/1.1 connections, not h2.
>
> Does this make sense?
>

+1 from me...

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2.4.27

William A Rowe Jr
In reply to this post by Stefan Eissing
+1 to removing support of mom prefork. I'd prefer it still start and if configured, with an [error] level alert in the logs and simply be disabled. Server must start when module is loaded but not configured, e.g. in test framework, IMO.

On Jul 6, 2017 10:31 AM, "Stefan Eissing" <[hidden email]> wrote:
Correction: websockets are not defined over h2. To make a more "real life" scenario:

One example is a long polling request by a javascript component. During the long poll, the browser will not get other responses.

More esoteric: when content filters (brotli, gzip) are in place, compression happens in the h2 worker thread. If one PUSHes such a resource, clients sometimes use h2 flow control to delay the sending of a response. This would deadlock the connection in a prefork model.

These are complications not easily debugged or reproducible.

> Am 06.07.2017 um 17:15 schrieb Stefan Eissing <[hidden email]>:
>
> Hej,
>
> I tried to gather some discussion about this. Should have polled this mailing list. You can read most of it here: https://github.com/icing/mod_h2/issues/142
>
> tl;dr
>
> I had several reports in the past of people being disappointed about h2 performance, only to learn they were on prefork. Which means every request is processed serially (with static files being an exception, as long as no filters prevent this).
>
> In 2.4.26 I changed the (undocumented) default from 1 to 4 h2 workers, which brought us to the issue I linked. The easy fix is 'H2MaxWorkers 1' in the config and you have the pre-2.4.26 behaviour.
>
> Regardless of the discussion if the change in 2.4.26 was reasonable or not: it is not possible to map the prefork single-thread requirement on to HTTP/2. Not going to work. One long running request, one websocket opened, and your browser will stall.
>
> This is not a bug, it is the collision of the processing models.
>
> So, I think disabling it prevent user from shooting themselves in the foot. If you are on prefork, you'd want the 6 parallel HTTP/1.1 connections, not h2.
>
> Does this make sense?
>
> Cheers,
>
> Stefan
>
> PS. Yes, I know that one /could/ make parallel processes work in prefork by placing the h2 dispatching in a parent process. If someone wants to implement that, be my guest.
>
>
>> Am 06.07.2017 um 16:55 schrieb Bert Huijben <[hidden email]>:
>>
>>
>>
>>> -----Original Message-----
>>> From: Jim Jagielski [mailto:[hidden email]]
>>> Sent: woensdag 5 juli 2017 18:49
>>> To: [hidden email]
>>> Subject: Re: 2.4.27
>>>
>>> These are just the fixes/regressions noted in CHANGES:
>>>
>>> Changes with Apache 2.4.27
>>>
>>> *) mod_lua: Improve compatibility with Lua 5.1, 5.2 and 5.3.
>>>    PR58188, PR60831, PR61245. [Rainer Jung]
>>>
>>> *) mod_http2: disable and give warning when mpm_prefork is
>>> encountered. The server will
>>>    continue to work, but HTTP/2 will no longer be negotiated. [Stefan
>> Eissing]
>>
>> Can somebody point me to the reasoning behind this?
>>
>> I have this configuration on FreeBSD with older Httpd versions, and it works
>> just fine for my limited load.
>>
>> Switching to a different model will require compiling more ports myself as
>> the FreeBSD packaging system is optimized for this model.
>>
>>
>> I do understand that there is a better mapping of http/2 streams with the
>> more modern MPMs, but there must be a reason that it worked and no longer
>> can be supported in the future. I assume this reason is already documented
>> somewhere...
>>
>> Thanks,
>>
>>      Bert
>>
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2.4.27

Reindl Harald-2


Am 06.07.2017 um 19:02 schrieb William A Rowe Jr:
> +1 to removing support of mom prefork. I'd prefer it still start and if
> configured, with an [error] level alert in the logs and simply be
> disabled. Server must start when module is loaded but not configured,
> e.g. in test framework, IMO

with removing mpm_prefork support for H2 you kill HTTP2 support for a
lot of production setups which may consider switch to H2 in the future
and for sure not rework there whole configuration but put a proxy like
Trafficserver in front and forget about httpd at this point at all

besides the technical consideration above - starting to ignore features
for mod_prefork in the middle of a lifetime cycle leaves a bad taste in
general

disclaimer: no i can't fix the issues - i have just my admin hat on
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2.4.27

Stefan Eissing
In reply to this post by William A Rowe Jr
It starts with a one time warning and will not negotiate. That's all. 

Am 06.07.2017 um 19:02 schrieb William A Rowe Jr <[hidden email]>:

+1 to removing support of mom prefork. I'd prefer it still start and if configured, with an [error] level alert in the logs and simply be disabled. Server must start when module is loaded but not configured, e.g. in test framework, IMO.

On Jul 6, 2017 10:31 AM, "Stefan Eissing" <[hidden email]> wrote:
Correction: websockets are not defined over h2. To make a more "real life" scenario:

One example is a long polling request by a javascript component. During the long poll, the browser will not get other responses.

More esoteric: when content filters (brotli, gzip) are in place, compression happens in the h2 worker thread. If one PUSHes such a resource, clients sometimes use h2 flow control to delay the sending of a response. This would deadlock the connection in a prefork model.

These are complications not easily debugged or reproducible.

> Am 06.07.2017 um 17:15 schrieb Stefan Eissing <[hidden email]>:
>
> Hej,
>
> I tried to gather some discussion about this. Should have polled this mailing list. You can read most of it here: https://github.com/icing/mod_h2/issues/142
>
> tl;dr
>
> I had several reports in the past of people being disappointed about h2 performance, only to learn they were on prefork. Which means every request is processed serially (with static files being an exception, as long as no filters prevent this).
>
> In 2.4.26 I changed the (undocumented) default from 1 to 4 h2 workers, which brought us to the issue I linked. The easy fix is 'H2MaxWorkers 1' in the config and you have the pre-2.4.26 behaviour.
>
> Regardless of the discussion if the change in 2.4.26 was reasonable or not: it is not possible to map the prefork single-thread requirement on to HTTP/2. Not going to work. One long running request, one websocket opened, and your browser will stall.
>
> This is not a bug, it is the collision of the processing models.
>
> So, I think disabling it prevent user from shooting themselves in the foot. If you are on prefork, you'd want the 6 parallel HTTP/1.1 connections, not h2.
>
> Does this make sense?
>
> Cheers,
>
> Stefan
>
> PS. Yes, I know that one /could/ make parallel processes work in prefork by placing the h2 dispatching in a parent process. If someone wants to implement that, be my guest.
>
>
>> Am 06.07.2017 um 16:55 schrieb Bert Huijben <[hidden email]>:
>>
>>
>>
>>> -----Original Message-----
>>> From: Jim Jagielski [mailto:[hidden email]]
>>> Sent: woensdag 5 juli 2017 18:49
>>> To: [hidden email]
>>> Subject: Re: 2.4.27
>>>
>>> These are just the fixes/regressions noted in CHANGES:
>>>
>>> Changes with Apache 2.4.27
>>>
>>> *) mod_lua: Improve compatibility with Lua 5.1, 5.2 and 5.3.
>>>    PR58188, PR60831, PR61245. [Rainer Jung]
>>>
>>> *) mod_http2: disable and give warning when mpm_prefork is
>>> encountered. The server will
>>>    continue to work, but HTTP/2 will no longer be negotiated. [Stefan
>> Eissing]
>>
>> Can somebody point me to the reasoning behind this?
>>
>> I have this configuration on FreeBSD with older Httpd versions, and it works
>> just fine for my limited load.
>>
>> Switching to a different model will require compiling more ports myself as
>> the FreeBSD packaging system is optimized for this model.
>>
>>
>> I do understand that there is a better mapping of http/2 streams with the
>> more modern MPMs, but there must be a reason that it worked and no longer
>> can be supported in the future. I assume this reason is already documented
>> somewhere...
>>
>> Thanks,
>>
>>      Bert
>>
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2.4.27

Helmut K. C. Tessarek
In reply to this post by Reindl Harald-2
On 2017-07-06 13:09, Reindl Harald wrote:
> with removing mpm_prefork support for H2 you kill HTTP2 support for a
> lot of production setups which may consider switch to H2 in the future
> and for sure not rework there whole configuration but put a proxy like
> Trafficserver in front and forget about httpd at this point at all

I respectfully disagree.

Removing h2 on prefork solves all issues that arise when used in this
context. You don't put diesel in your car, when your engine is for
regular gas. Why? Because it won't work and might screw up your engine.

Same applies to h2 and prefork.

--
regards Helmut K. C. Tessarek
lookup https://sks-keyservers.net/i for KeyID 0xC11F128D

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2.4.27

William A Rowe Jr
On Thu, Jul 6, 2017 at 12:20 PM, Helmut K. C. Tessarek
<[hidden email]> wrote:

> On 2017-07-06 13:09, Reindl Harald wrote:
>> with removing mpm_prefork support for H2 you kill HTTP2 support for a
>> lot of production setups which may consider switch to H2 in the future
>> and for sure not rework there whole configuration but put a proxy like
>> Trafficserver in front and forget about httpd at this point at all
>
> I respectfully disagree.
>
> Removing h2 on prefork solves all issues that arise when used in this
> context. You don't put diesel in your car, when your engine is for
> regular gas. Why? Because it won't work and might screw up your engine.
>
> Same applies to h2 and prefork.

Well put. Confirming what Stefan wrote... the following appears in the error log
at startup;

[Thu Jul 06 12:18:58.005442 2017] [http2:warn] [pid 30121] AH10034:
The mpm module (prefork.c) is not supported by mod_http2. The mpm
determines how things are processed in your server. HTTP/2 has more
demands in this regard and the currently selected mpm will just not
do. This is an advisory warning. Your server will continue to work,
but the HTTP/2 protocol will be inactive.

Go ahead and build all mpm's - default to prefork, enable http2. Nothing
is wrong, but http:// connections won't transition to h2, that is all.

Building prefork also doesn't disable mod_http2 by default, which is good,
because I would expect that to cause http2 to not be built when building all
mpm's in one go.

The 2.4 tree looks good for tagging.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2.4.27

Jacob Champion-2
In reply to this post by Reindl Harald-2
On 07/06/2017 10:09 AM, Reindl Harald wrote:
> with removing mpm_prefork support for H2 you kill HTTP2 support for a
> lot of production setups which may consider switch to H2 in the future
> and for sure not rework there whole configuration but put a proxy like
> Trafficserver in front and forget about httpd at this point at all

I think the fallout is more nuanced than that. The mod_http2
architecture currently cannot be mixed with prefork; it can lead to
deadlock, and that's not okay for production systems in any way.

Administrators using prefork who would like to switch to HTTP/2 in the
future need to understand the limitations of the prefork architecture
they have selected. And sure, our users can request that we implement a
solution that "just works" with prefork, with the parent dispatcher that
Stefan has mentioned, and we can weigh the cost/benefit of implementing
it. But IMO it's not that onerous to ask our users to upgrade to a
modern MPM if they want a nice new protocol.

There are costs to making new things work with old machinery, and they
affect you (the users) in real ways, even if you do not see them yourself.

--Jacob
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2.4.27

William A Rowe Jr
On Thu, Jul 6, 2017 at 12:28 PM, Jacob Champion <[hidden email]> wrote:
>
> Administrators using prefork who would like to switch to HTTP/2 in the
> future need to understand the limitations of the prefork architecture they
> have selected. And sure, our users can request that we implement a solution
> that "just works" with prefork, with the parent dispatcher that Stefan has
> mentioned, and we can weigh the cost/benefit of implementing it. But IMO
> it's not that onerous to ask our users to upgrade to a modern MPM if they
> want a nice new protocol.

Agreed. Handling connections and requests on a 1:1 basis gains little from h2
protocol, other than a different path to TLS handshaking. As the h2 protocol
corrupted the OSI model and wire format in the first place, clients are forced
to deterministically wiggle their way into an h2 connection without telegraphing
that dance to the end-user. So this should be completely opaque to the client's
user, and similarly opaque to the server admin.

The parent (root) process can never serve as the actual traffic dispatcher,
much too risky. So the parent or a dedicated spawned process (preferable)
would have to triage all the requests for child workers to an h2 connection
by dispatching unix domain sockets between the connection's worker and
the individual request workers, and then let them exchange data through
the socket, because shared memory between connection and request
workers would not behave the same way.

In short, it would be an entirely new level of complexity, which the current
project maintainers have no interest in engaging in. This worked with the
mod_ftp only because the control channel (similar to the connection thread)
has absolutely nothing to do during the singular data channel exchange,
other than be watched for an ABOR; no other command is valid. h2 needs
to lookaside for control directives from the connection channel while it is
servicing each of the request workers.

Prefork exists only because http/1 is a synchronous protocol, in that the
server reads the user-agent's instructions and is left to act on that method
and resource, with no other client interaction other than 101 continue or
102 upgrade (101 was especially disruptive but still largely ping-pong.)
If the original protocol were http/2, prefork would never have been introduced.

It's 2017. I've been threading my logic now over 30 years. Maybe it's time
that Unix library developers and php community wake up to a new century?
But as long as the fastcgi model persists, there is really no need to worry
about any of this; run a threaded server and an fcgi pool of php app servers.
12
Loading...