You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2017/07/03 11:33:01 UTC
2.4.27
Anyone opposed to a quick T&R and release of 2.4.27 within
the next week?
Re: 2.4.27
Posted by Jacob Champion <ch...@gmail.com>.
On 07/03/2017 04:45 AM, Eric Covener wrote:
> +1
+1
--Jacob
Re: 2.4.27
Posted by Eric Covener <co...@gmail.com>.
On Mon, Jul 3, 2017 at 7:34 AM, Stefan Eissing
<st...@greenbytes.de> wrote:
> +1
>
> (read: all for it to happen)
+1
Re: 2.4.27
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 03.07.2017 um 13:33 schrieb Jim Jagielski <ji...@jaguNET.com>:
>
> Anyone opposed to a quick T&R and release of 2.4.27 within
> the next week?
+1
(read: all for it to happen)
Re: 2.4.27
Posted by "Helmut K. C. Tessarek" <te...@evermeet.cx>.
On 2017-07-18 12:54, Yann Ylavic wrote:
> You should probably re-check with latest 2.4.27, where some
> regressions with regard to php-fpm (since 2.4.20) where finally
> addressed (see https://bz.apache.org/bugzilla/show_bug.cgi?id=61202).
I did. 2.4.27 fixed a proxy_fcgi problem and nextcloud:
https://github.com/nextcloud/server/issues/5660
It didn't help with the rewrite issue.
--
regards Helmut K. C. Tessarek KeyID 0xF7832007C11F128D
Key fingerprint = 28A3 1666 4FE8 D72C CFD5 8B23 F783 2007 C11F 128D
/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/
Re: 2.4.27
Posted by "Helmut K. C. Tessarek" <te...@evermeet.cx>.
On 2017-07-18 14:25, Eric Covener wrote:
> Argh, not right, missed the other return stmt.
>
> It seems like proxy_trans will return OK to translate_name() and not
> let mod_rewrite in non-perdir run at all. It is rigged to run before
> mod_rewrite.
Ok, it seems that my rewrite issue has gained a bit of attention, thus I
will explain it now in more detail (otherwise people don't know what I
am actually talking about):
<Directory "/var/www">
Options FollowSymLinks
AllowOverride None
ErrorDocument 404 /404.php
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([^\.]+)$ $1.php [NC,L]
Require all granted
</Directory>
With mod_php I got the 404.php error page when going to:
https://example.com/te
With mod_proxy_fcgi I get a "File not found." error in the browser and
the following is in Apache's error_log:
[proxy_fcgi:error] AH01071: Got error 'Primary script unknown\n'
However, I get the 404.php error page, when going to:
https://example.com/te.t
https://example.com/te/
(So it works partly with proxy_fcgi.)
I'm still investigating why that is. I'm a bit pressed for time that's
why I haven't been able to look into it in more detail.
I have to setup a VM to debug this further, but IMO this is not ok.
In both cases the rewrite should work the same way.
My handler cfg looks like this:
<FilesMatch "\.php$">
SetHandler "proxy:unix:/var/run/php7-fpm/sample.sock|fcgi://sample"
</FilesMatch>
A rather simple use case, yet the bahaviour is different. Don't get me
wrong, but it shouldn't behave differently.
--
regards Helmut K. C. Tessarek KeyID 0xF7832007C11F128D
Key fingerprint = 28A3 1666 4FE8 D72C CFD5 8B23 F783 2007 C11F 128D
/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/
Re: 2.4.27
Posted by Eric Covener <co...@gmail.com>.
On Tue, Jul 18, 2017 at 2:24 PM, Eric Covener <co...@gmail.com> wrote:
> On Tue, Jul 18, 2017 at 12:54 PM, Yann Ylavic <yl...@gmail.com> wrote:
>> On Tue, Jul 18, 2017 at 6:27 PM, Helmut K. C. Tessarek
>> <te...@evermeet.cx> wrote:
>>>
>>> Have you seen this sentence?
>>>
>>>>> So ProxyPass has precedence over other directives. It is evaluated
>>>>> first. This can lead to a number of problems.
>>
>> ProxyPass has no particular precedence over other directives, it's
>> just that some of them have no meaning is proxy context: e.g.
>> <Directory> (as you mentioned).
>>
>
> In the case of ProxyPass vs. non per-dir rewrites, you will see at
> least a change REQUEST_FILENAME (which in non-perdir w/o mod_proxy
> matching is the same as REQUEST_URI and really is a bad idea to use!)
Argh, not right, missed the other return stmt.
It seems like proxy_trans will return OK to translate_name() and not
let mod_rewrite in non-perdir run at all. It is rigged to run before
mod_rewrite.
--
Eric Covener
covener@gmail.com
Re: 2.4.27
Posted by Eric Covener <co...@gmail.com>.
On Tue, Jul 18, 2017 at 12:54 PM, Yann Ylavic <yl...@gmail.com> wrote:
> On Tue, Jul 18, 2017 at 6:27 PM, Helmut K. C. Tessarek
> <te...@evermeet.cx> wrote:
>>
>> Have you seen this sentence?
>>
>>>> So ProxyPass has precedence over other directives. It is evaluated
>>>> first. This can lead to a number of problems.
>
> ProxyPass has no particular precedence over other directives, it's
> just that some of them have no meaning is proxy context: e.g.
> <Directory> (as you mentioned).
>
In the case of ProxyPass vs. non per-dir rewrites, you will see at
least a change REQUEST_FILENAME (which in non-perdir w/o mod_proxy
matching is the same as REQUEST_URI and really is a bad idea to use!)
Re: 2.4.27
Posted by Yann Ylavic <yl...@gmail.com>.
On Tue, Jul 18, 2017 at 6:27 PM, Helmut K. C. Tessarek
<te...@evermeet.cx> wrote:
>
> Have you seen this sentence?
>
>>> So ProxyPass has precedence over other directives. It is evaluated
>>> first. This can lead to a number of problems.
ProxyPass has no particular precedence over other directives, it's
just that some of them have no meaning is proxy context: e.g.
<Directory> (as you mentioned).
<Directory*> and <File*> apply to local/served paths and files
(served), while proxying is about remote/forwarded ones, that is: a
<Location>.
>
> I stated that mod_rewrite behaves differently when using mod_php and
> mod_proxy_fcgi. This sounds more like a bug, because it really shouldn't.
>
> I used rewrite with mod_php. It worked.
> Then I switched to mod_proxy_fcgi. Now it does not.
>
> So why is that? I also mentioned I have to debug it further.
You should probably re-check with latest 2.4.27, where some
regressions with regard to php-fpm (since 2.4.20) where finally
addressed (see https://bz.apache.org/bugzilla/show_bug.cgi?id=61202).
Regards,
Yann.
Re: 2.4.27
Posted by "Helmut K. C. Tessarek" <te...@evermeet.cx>.
Hi David,
Thanks for your reply, but I have already established in my previous
email what the order of evaluation is.
Have you seen this sentence?
>> So ProxyPass has precedence over other directives. It is evaluated
>> first. This can lead to a number of problems.
On 2017-07-18 09:33, David Zuelke wrote:
> You need to use SetHandler. You can't use rewrites with ProxyPass
> because of the order of evaluation.
I am. I have never used anything else but SetHandler.
I think I explained in the mail you replied to what I think of ProxyPass.
> Further questions should be taken to the users list though, as this
> one here is for development of httpd...
I believe you did not read my email or read something into it. This is
not a user question. I know how to use mod_rewrite.
I stated that mod_rewrite behaves differently when using mod_php and
mod_proxy_fcgi. This sounds more like a bug, because it really shouldn't.
I used rewrite with mod_php. It worked.
Then I switched to mod_proxy_fcgi. Now it does not.
So why is that? I also mentioned I have to debug it further.
--
regards Helmut K. C. Tessarek KeyID 0xF7832007C11F128D
Key fingerprint = 28A3 1666 4FE8 D72C CFD5 8B23 F783 2007 C11F 128D
/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/
Re: 2.4.27
Posted by David Zuelke <dz...@heroku.com>.
You need to use SetHandler. You can't use rewrites with ProxyPass because of the order of evaluation.
Example config:
Define php-fpm unix:/tmp/php-fpm.sock|fcgi://php-fpm
# make sure the proxy is registered with the unix socket; we can then use just "fcgi://php-fpm" in proxy and rewrites directives
# we have to do this because we can't rewrite to a UDS location and because PHP doesn't support the unix:...|fcgi://... syntax
# this is also a lot more convenient for users
# http://thread.gmane.org/gmane.comp.apache.devel/52892
<Proxy "${php-fpm}">
# we must declare a parameter in here or it'll not register the proxy ahead of time
# min=0 is an obvious candidate since that's the default value already and sensible
ProxySet min=0
</Proxy>
<VirtualHost ...>
# pass requests to .php files to mod_proxy_fcgi
# this requires Apache 2.4.10+ and PHP 5.5.15+ to work properly
<FilesMatch \.php$>
<If "-f %{REQUEST_FILENAME}"> # make sure the file exists so that if not, Apache will show its 404 page and not FPM
SetHandler proxy:fcgi://php-fpm
</If>
</FilesMatch>
</VirtualHost>
You can then simply rewrite to index.php etc, and it'll work.
Further questions should be taken to the users list though, as this one here is for development of httpd...
> On 17. Jul 2017, at 19:25, Helmut K. C. Tessarek <te...@evermeet.cx> wrote:
>
> On 2017-07-17 03:50, Luca Toscano wrote:
>> mod-proxy-fcgi is the preferred solution over mod-fcgi, and we have
>> documentation about it. Any specific reason to use libapache2-mod-fcgid?
>> (asking for curiosity and/or to decide if a doc update is needed :)
>
> I am using mod_proxy_fcgi exactly for that reason (stated on
> https://wiki.apache.org/httpd/php). But the documentation
> (https://wiki.apache.org/httpd/PHP-FPM) is IMO a bit off.
>
>> Can you please be more specific? What errors do you see? In case please
>> open a task in bugzilla so we'll be able to debug it :)
>
> Even according to the documentation for mod_proxy_fcgi, UDS does not
> support connection reuse.
> In my case it broke POST requests. I then googled and found a bunch of
> articles and stackexchange entries that suggested to remove the
> enablereuse=on option from the Proxy section.
>
> Only after removing the Proxy directive completely, everything started
> to work as expected.
>
> Except from the mod_rewrite issue I experience. I'm still debugging it,
> but mod_rewrite behaves differently between mod_php and mod_proxy_fcgi,
> which should not happen at all, since rewrite shouldn't care or know
> about the backend. I also googled and found a few entries, none of which
> helped me:
>
> https://stackoverflow.com/questions/44054617/mod-rewrite-in-2-4-25-triggering-fcgi-primary-script-unknown-error-in-php-fpm
>
> http://www.coders.pro/2017/01/qq-htm/
>
>> Using ProxyPassMatch is not only dangerous, it also has precedence over
>> a FilesMatch directive, which in turn limits your ability to restrict
>> access to certain resources. At least that was the case a couple of
>> years back.
>>
>> Dangerous in what way? Can you please be more specific and/or add examples?
>
> I'm sorry, my bad. I should not have generalized it. ProxyPass and
> ProxyPassMatch _can_ be dangerous. I see 2 main issues:
>
> 1) The match part can be set too wide, which could allow php-fpm to
> interpret the wrong file.
>
> 2) The documentation also states:
> Warning: when you ProxyPass a request to another server (in this case,
> the php-fpm daemon), authentication restrictions, and other
> configurations placed in a Directory block or .htaccess file, may be
> bypassed.
>
> So ProxyPass has precedence over other directives. It is evaluated
> first. This can lead to a number of problems.
> Anyway, as long as you are aware of it, the impact can be minimized. Yet
> I believe it is too dangerous for the average Joe.
>
> --
> regards Helmut K. C. Tessarek KeyID 0xF7832007C11F128D
> Key fingerprint = 28A3 1666 4FE8 D72C CFD5 8B23 F783 2007 C11F 128D
>
> /*
> Thou shalt not follow the NULL pointer for chaos and madness
> await thee at its end.
> */
Re: 2.4.27
Posted by "Helmut K. C. Tessarek" <te...@evermeet.cx>.
On 2017-07-17 03:50, Luca Toscano wrote:
> mod-proxy-fcgi is the preferred solution over mod-fcgi, and we have
> documentation about it. Any specific reason to use libapache2-mod-fcgid?
> (asking for curiosity and/or to decide if a doc update is needed :)
I am using mod_proxy_fcgi exactly for that reason (stated on
https://wiki.apache.org/httpd/php). But the documentation
(https://wiki.apache.org/httpd/PHP-FPM) is IMO a bit off.
> Can you please be more specific? What errors do you see? In case please
> open a task in bugzilla so we'll be able to debug it :)
Even according to the documentation for mod_proxy_fcgi, UDS does not
support connection reuse.
In my case it broke POST requests. I then googled and found a bunch of
articles and stackexchange entries that suggested to remove the
enablereuse=on option from the Proxy section.
Only after removing the Proxy directive completely, everything started
to work as expected.
Except from the mod_rewrite issue I experience. I'm still debugging it,
but mod_rewrite behaves differently between mod_php and mod_proxy_fcgi,
which should not happen at all, since rewrite shouldn't care or know
about the backend. I also googled and found a few entries, none of which
helped me:
https://stackoverflow.com/questions/44054617/mod-rewrite-in-2-4-25-triggering-fcgi-primary-script-unknown-error-in-php-fpm
http://www.coders.pro/2017/01/qq-htm/
> Using ProxyPassMatch is not only dangerous, it also has precedence over
> a FilesMatch directive, which in turn limits your ability to restrict
> access to certain resources. At least that was the case a couple of
> years back.
>
> Dangerous in what way? Can you please be more specific and/or add examples?
I'm sorry, my bad. I should not have generalized it. ProxyPass and
ProxyPassMatch _can_ be dangerous. I see 2 main issues:
1) The match part can be set too wide, which could allow php-fpm to
interpret the wrong file.
2) The documentation also states:
Warning: when you ProxyPass a request to another server (in this case,
the php-fpm daemon), authentication restrictions, and other
configurations placed in a Directory block or .htaccess file, may be
bypassed.
So ProxyPass has precedence over other directives. It is evaluated
first. This can lead to a number of problems.
Anyway, as long as you are aware of it, the impact can be minimized. Yet
I believe it is too dangerous for the average Joe.
--
regards Helmut K. C. Tessarek KeyID 0xF7832007C11F128D
Key fingerprint = 28A3 1666 4FE8 D72C CFD5 8B23 F783 2007 C11F 128D
/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/
Re: 2.4.27
Posted by James Cloos <cl...@jhcloos.com>.
>>>>> "LT" == Luca Toscano <to...@gmail.com> writes:
LT> mod-proxy-fcgi is the preferred solution over mod-fcgi, and we have
LT> documentation about it. Any specific reason to use libapache2-mod-fcgid?
LT> (asking for curiosity and/or to decide if a doc update is needed :)
It was all I found via apt-cache search.
I've now found https://httpd.apache.org/docs/2.4/mod/mod_proxy_fcgi.html
and its Proxy via Handler section. None of the docs I found before pointed
there.
LT> Can you please be more specific? What errors do you see? In case please
LT> open a task in bugzilla so we'll be able to debug it :)
I tried everything I found via a goog search. Each time, the php was
returned to the browser unevaluated.
-JimC
--
James Cloos <cl...@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6
Re: 2.4.27
Posted by Luca Toscano <to...@gmail.com>.
Hi James and Helmut,
2017-07-17 0:59 GMT+02:00 Helmut K. C. Tessarek <te...@evermeet.cx>:
> On 2017-07-16 18:41, James Cloos wrote:
> > And I've not found any *working* documentation on how to switch to using
> > php7.0-fpm and libapache2-mod-fcgid.
>
mod-proxy-fcgi is the preferred solution over mod-fcgi, and we have
documentation about it. Any specific reason to use libapache2-mod-fcgid?
(asking for curiosity and/or to decide if a doc update is needed :)
>
> Yea, the documentation on https://wiki.apache.org/httpd/PHP-FPM is also
> flawed.
>
> e.g. if you use the proxy option enablereuse=on in a proxy_fcgi setup
> that uses sockets, you are screwed. The entire setup blows up.
>
Can you please be more specific? What errors do you see? In case please
open a task in bugzilla so we'll be able to debug it :)
>
> Using ProxyPassMatch is not only dangerous, it also has precedence over
> a FilesMatch directive, which in turn limits your ability to restrict
> access to certain resources. At least that was the case a couple of
> years back.
>
Dangerous in what way? Can you please be more specific and/or add examples?
Thanks!
Luca
Re: 2.4.27
Posted by "Helmut K. C. Tessarek" <te...@evermeet.cx>.
On 2017-07-16 18:41, James Cloos wrote:
> And I've not found any *working* documentation on how to switch to using
> php7.0-fpm and libapache2-mod-fcgid.
Yea, the documentation on https://wiki.apache.org/httpd/PHP-FPM is also
flawed.
e.g. if you use the proxy option enablereuse=on in a proxy_fcgi setup
that uses sockets, you are screwed. The entire setup blows up.
Using ProxyPassMatch is not only dangerous, it also has precedence over
a FilesMatch directive, which in turn limits your ability to restrict
access to certain resources. At least that was the case a couple of
years back.
--
regards Helmut K. C. Tessarek KeyID 0xF7832007C11F128D
Key fingerprint = 28A3 1666 4FE8 D72C CFD5 8B23 F783 2007 C11F 128D
/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/
Re: 2.4.27
Posted by James Cloos <cl...@jhcloos.com>.
>>>>> Jim Riggs <ap...@riggs.me> writes:
> See previous discussion in the "2.4.27" thread, specifically:
> https://lists.apache.org/thread.html/bae472cadaeeb761b88bb4569cc0b7d87bc2dcb2fbcbf472d895f32e@%3Cdev.httpd.apache.org%3E
I did see that after my initial reply.
Still anoying.
And I've not found any *working* documentation on how to switch to using
php7.0-fpm and libapache2-mod-fcgid.
-JimC
--
James Cloos <cl...@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6
Re: 2.4.27
Posted by Jim Riggs <ap...@riggs.me>.
> On 11 Jul 2017, at 11:46, James Cloos <cl...@jhcloos.com> wrote:
>
>>>>>> "JJ" == Jim Jagielski <ji...@jaguNET.com> writes:
>
> JJ> *) mod_http2: disable and give warning when mpm_prefork is encountered. The server will
> JJ> continue to work, but HTTP/2 will no longer be negotiated. [Stefan Eissing]
>
> Why break h2 w/ prefork.
>
> AIUI, one still needs to use prefork with the perl and php modules.
>
> And it works fine here with 2.4.25.
>
> That change makes 2.4.27 worthless.
See previous discussion in the "2.4.27" thread, specifically:
https://lists.apache.org/thread.html/bae472cadaeeb761b88bb4569cc0b7d87bc2dcb2fbcbf472d895f32e@%3Cdev.httpd.apache.org%3E
Re: 2.4.27
Posted by James Cloos <cl...@jhcloos.com>.
>>>>> "JJ" == Jim Jagielski <ji...@jaguNET.com> writes:
JJ> *) mod_http2: disable and give warning when mpm_prefork is encountered. The server will
JJ> continue to work, but HTTP/2 will no longer be negotiated. [Stefan Eissing]
Why break h2 w/ prefork.
AIUI, one still needs to use prefork with the perl and php modules.
And it works fine here with 2.4.25.
That change makes 2.4.27 worthless.
-JimC
--
James Cloos <cl...@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6
Re: 2.4.27
Posted by Eric Covener <co...@gmail.com>.
On Thu, Jul 6, 2017 at 10:55 AM, Bert Huijben <be...@qqmail.nl> 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
covener@gmail.com
Re: 2.4.27
Posted by Graham Leggett <mi...@sharp.fm>.
On 06 Jul 2017, at 5:15 PM, Stefan Eissing <st...@greenbytes.de> wrote:
> 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?
It does, +1.
> 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.
I've looked at this in some detail. There are a number of limitations that need lifting in the core, one of which is that connections need to be able to return EAGAIN. I have a plan for this, but I am slammed right now.
Regards,
Graham
—
Re: 2.4.27
Posted by Stefan Eissing <st...@greenbytes.de>.
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 <wr...@rowe-clan.net>:
>
> +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" <st...@greenbytes.de> 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 <st...@greenbytes.de>:
>> >
>> > 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 <be...@qqmail.nl>:
>> >>
>> >>
>> >>
>> >>> -----Original Message-----
>> >>> From: Jim Jagielski [mailto:jim@jaguNET.com]
>> >>> Sent: woensdag 5 juli 2017 18:49
>> >>> To: dev@httpd.apache.org
>> >>> 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
>> >>
>> >>
>> >
>>
Re: 2.4.27
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Jul 6, 2017 at 12:20 PM, Helmut K. C. Tessarek
<te...@evermeet.cx> 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.
Re: 2.4.27
Posted by "Helmut K. C. Tessarek" <te...@evermeet.cx>.
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.
*/
Re: 2.4.27
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Jul 6, 2017 at 12:28 PM, Jacob Champion <ch...@gmail.com> 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.
Re: 2.4.27
Posted by "Helmut K. C. Tessarek" <te...@evermeet.cx>.
On 2017-07-11 08:55, David Zuelke wrote:
> That PHP bug affects parsing of PHP-FPM's config file. It has nothing
> to do with the FastCGI interface or its runtime behavior.
Nope, it also fixed a web application for me.
see https://github.com/nextcloud/server/issues/5660
--
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.
*/
Re: 2.4.27
Posted by Reindl Harald <h....@thelounge.net>.
Am 11.07.2017 um 14:55 schrieb David Zuelke:
> On 10. Jul 2017, at 16:04, Reindl Harald <h....@thelounge.net> wrote:
>>
>> Am 06.07.2017 um 19:28 schrieb Jacob Champion:
>>> 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
>>
>> well, when i see how fragile the combination of httpd and php-fpm still is, thanks, but no
>>
>> Apache:
>> COMPATIBILITY: mod_proxy_fcgi: Revert to 2.4.20 FCGI behavior for the default ProxyFCGIBackendType, fixing a regression with PHP-FPM. PR 61202
>>
>> PHP:
>> Fixed bug #74738 (Multiple [PATH=] and [HOST=] sections not properly parsed).
>> https://bugs.php.net/bug.php?id=74738
>
> That PHP bug affects parsing of PHP-FPM's config file. It has nothing to do with the FastCGI interface or its runtime behavior
fine, but i can't remember something similar in the past 15 years with
mod_php and that this makes it to stable releases when php-fpm is "the
new way to go" for a longer time is not the best sign
Re: 2.4.27
Posted by David Zuelke <dz...@heroku.com>.
On 10. Jul 2017, at 16:04, Reindl Harald <h....@thelounge.net> wrote:
>
> Am 06.07.2017 um 19:28 schrieb Jacob Champion:
>> 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
>
> well, when i see how fragile the combination of httpd and php-fpm still is, thanks, but no
>
> Apache:
> COMPATIBILITY: mod_proxy_fcgi: Revert to 2.4.20 FCGI behavior for the default ProxyFCGIBackendType, fixing a regression with PHP-FPM. PR 61202
>
> PHP:
> Fixed bug #74738 (Multiple [PATH=] and [HOST=] sections not properly parsed).
> https://bugs.php.net/bug.php?id=74738
That PHP bug affects parsing of PHP-FPM's config file. It has nothing to do with the FastCGI interface or its runtime behavior.
Re: 2.4.27
Posted by Reindl Harald <h....@thelounge.net>.
Am 06.07.2017 um 19:28 schrieb Jacob Champion:
> 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
well, when i see how fragile the combination of httpd and php-fpm still
is, thanks, but no
Apache:
COMPATIBILITY: mod_proxy_fcgi: Revert to 2.4.20 FCGI behavior for the
default ProxyFCGIBackendType, fixing a regression with PHP-FPM. PR 61202
PHP:
Fixed bug #74738 (Multiple [PATH=] and [HOST=] sections not properly
parsed).
https://bugs.php.net/bug.php?id=74738
Re: 2.4.27
Posted by Jacob Champion <ch...@gmail.com>.
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
Re: 2.4.27
Posted by Reindl Harald <h....@thelounge.net>.
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
Re: 2.4.27
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
+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" <st...@greenbytes.de>
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 <
> stefan.eissing@greenbytes.de>:
> >
> > 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 <be...@qqmail.nl>:
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Jim Jagielski [mailto:jim@jaguNET.com]
> >>> Sent: woensdag 5 juli 2017 18:49
> >>> To: dev@httpd.apache.org
> >>> 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
> >>
> >>
> >
>
>
Re: 2.4.27
Posted by Stefan Eissing <st...@greenbytes.de>.
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 <st...@greenbytes.de>:
>
> 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 <be...@qqmail.nl>:
>>
>>
>>
>>> -----Original Message-----
>>> From: Jim Jagielski [mailto:jim@jaguNET.com]
>>> Sent: woensdag 5 juli 2017 18:49
>>> To: dev@httpd.apache.org
>>> 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
>>
>>
>
Re: 2.4.27
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Jul 6, 2017, at 11:15 AM, Stefan Eissing <st...@greenbytes.de> 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...
Re: 2.4.27
Posted by Stefan Eissing <st...@greenbytes.de>.
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 <be...@qqmail.nl>:
>
>
>
>> -----Original Message-----
>> From: Jim Jagielski [mailto:jim@jaguNET.com]
>> Sent: woensdag 5 juli 2017 18:49
>> To: dev@httpd.apache.org
>> 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
>
>
RE: 2.4.27
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Jim Jagielski [mailto:jim@jaguNET.com]
> Sent: woensdag 5 juli 2017 18:49
> To: dev@httpd.apache.org
> 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
Re: 2.4.27
Posted by Christian Folini <ch...@netnea.com>.
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 <ch...@netnea.com> 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 - <ch...@netnea.com>
--
Christian Folini - <ch...@netnea.com>
Re: 2.4.27
Posted by Jim Jagielski <ji...@jaguNET.com>.
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 <ch...@netnea.com> 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 - <ch...@netnea.com>
Re: 2.4.27
Posted by Christian Folini <ch...@netnea.com>.
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 - <ch...@netnea.com>
Re: 2.4.27
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
+1
On Jul 3, 2017 6:33 AM, "Jim Jagielski" <ji...@jagunet.com> wrote:
> Anyone opposed to a quick T&R and release of 2.4.27 within
> the next week?
>