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" <stefan.eiss...@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.eiss...@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 <b...@qqmail.nl>: >> >> >> >> >> >> >> >>> -----Original Message----- >> >>> From: Jim Jagielski [mailto:j...@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 >> >> >> >> >> > >>
