HTTP/2 support in php:7.2-apache-stretch image

[Sahadar]

Hello,
I have faced issue with http/2 using php:7.2-apache-stretch image.
While running apache having such modules enabled:

a2enmod rewrite
a2enmod headers
a2enmod http2
a2enmod ssl

With configuration (http2.conf included in /etc/apache2/conf-enabled/000-http2.conf):

Protocols h2 h2c http/1.1

H2Push on
H2PushPriority * after
H2PushPriority text/css before
H2PushPriority image/jpeg after 32
H2PushPriority image/png after 32
H2PushPriority application/javascript interleaved

SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-A$'`

Apache says:
[http2:warn] [pid 65] 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.

After switching to mpm_event, another issue occurs:
[php7:crit] [pid 131:tid 140261273732288] Apache is running a threaded MPM, but your PHP Module is not compiled to be threadsafe. You need to recompile PHP. AH00013: Pre-configuration failed

Thanks in advance for any help.

[tianon]

Is Apache a hard requirement for your deployment?

I think the easiest way to use HTTP/2 with this image today would be to instead use the FPM variants and connect them via NGINX instead (or another load balancer / reverse proxy).

[Sahadar]

Apache is not a hard requirement on my production. I was just curious if the problem stays on my side. I remember that while ALPN was not a hard requirement for HTTP/2 then everything worked fine with your docker images.
Switching to PHP-FPM + NGINX should not be a problem but will have to learn something about that FPM. No experience at all.
On the other hand, I will be waiting for other solutions to this problem using "php:7.2-apache-stretch" image.

[LouWii]

I'm currently working on setting up HTTP/2 on the php:7.1-apache-stretch image, but the process is the same.

I believe the issue you have is because you're not using PHP FPM with fastCGI as it seems to be a requirement. And that's where I'm stuck right now, as there's no php:7.1-fpm-apache-stretch image.

I was thinking of just installing the php7.1-fpm package via apt on php:7.1-apache-stretch but I don't think that's a good idea (although I did it and it works). I believe the solution would be to start from php:7.1-fpm-stretch and then install apache and set it up properly. That's if you want to have a all-in-one container running PHP + Apache with HTTP/2.

I wish there was a php:7.1-fpm-apache-stretch image, it would make things easier (and could offer HTTP/2 support OOTB). I wonder if a pull request for that would be accepted.

[tianon]

I'm not sure why you'd want to use Apache and FPM together, but even more confused why you'd want the two things running in the same container? Typically I see folks using FPM in conjunction with something like NGINX to do the FastCGI handshaking/request handoff, but it should be relatively simple to configure Apache to do something similar (https://httpd.apache.org/docs/2.4/mod/mod_proxy_fcgi.html).

The Apache variants of this image use mod_php, which is (as far as I know) upstream's recommended method for using Apache and PHP together.

[LouWii]

The combo Apache + PHP-FPM is quite popular for running web servers. It's probably not the best, but I believe it performs better than mod_php.

Running Apache + PHP-FPM in one container might be a weird idea, but it's the only solution for having an Apache + PHP 2-in-1 container that's HTTP/2 compatible. I believe I'm not the only one with that need (dpfaffenbauer/pimcore-docker#5 is one example).

[ghost]

I'm not sure if this helps, but I made a all-in-one container with debian:stretch, php7.2 and mod_http2:
https://gist.github.com/lunamanuel/3a8de9fe3a84cf52e447d9346d9c6687

[scottconnerly]

Updating to use a more modern mpm for Apache would be a good idea anyways per https://serverfault.com/a/383634/93416
It seems to disagree with this repo's comment that "Apache + PHP requires preforking Apache for best results"

Or at least compiling this PHP to be thread-safe so we could switch mpm's ourselves.
Lots of reading on PHP thread safety: https://stackoverflow.com/a/5978844/218967

Interesting that PHP themselves say "don't":
http://www.php.net/manual/en/install.unix.apache2.php
https://secure.php.net/manual/en/faq.installation.php#faq.installation.apache2
Sadly, with little detail other than "its hard to troubleshoot".

But I'd definitely be interested in PHP being compiled thread-safe, even if this container's default mpm remains prefork.

Formal request:

Please enable thread safety.

UPDATE:
I see #742 now, and that it's already underway with #785 . Awesome.
And I've learned pthreads isn't a requirement for this. --enable-maintainer-zts is a requirement for pthreads. Got my wires crossed, thanks for listening.

[tianon]

See especially #742 (comment); there's a nontrivial performance hit for enabling ZTS.

[PeterDraex]

Is there any update on this? Still no HTTP/2 support in sight in June 2020?

cc @tianon

[ax2009live]

Still no HTTP/2 support in sight in February 2021? 💔💔💔😭😭😭
SSL and HTTP/2 are enabled by default, Isn't that good?

[tianon]

The limitations which prevent us from enabling it by default still unfortunately apply:

[Fri Feb 18 01:58:25.251249 2022] [http2:warn] [pid 18] 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.

Using mod_php with a threaded mpm requires PHP itself to be compiled with ZTS, which as noted above, has a non-trivial performance hit.

PHP with Apache and mod_php is definitely the easiest way to run a stable PHP site, but IMO it is unfortunately not the best way.