2018-02-02 12:20 GMT+01:00 Hajo Locke <hajo.lo...@gmx.de>: > > > Am 02.02.2018 um 07:05 schrieb Luca Toscano: > > Hello Hajo, > > 2018-02-01 13:20 GMT+01:00 Hajo Locke <hajo.lo...@gmx.de>: > >> Hello Luca, >> >> Am 01.02.2018 um 09:10 schrieb Hajo Locke: >> >> Hello Luca, >> >> Am 01.02.2018 um 04:46 schrieb Luca Toscano: >> >> Hi Hajo, >> >> 2018-01-31 1:27 GMT-08:00 Hajo Locke <hajo.lo...@gmx.de>: >> >>> Hello List, >>> >>> currently i compare features and behaviour of proxy_fcgi to classical >>> methods like mod_fastcgi/mod_php. >>> >>> mod_php/fastcgi have options to send every output from backend >>> immediately to client. So it is possible to see progressing output in >>> browser and not complete websiteoutput at once. >>> >>> Here is an example script: >>> https://pastebin.com/4drpgBMq >>> >>> if you ran this with php-cli or adjusted mod_php/mod_fastcgi you see >>> progress in browser and numbers 0 1 2 appear one after another. >>> If you run this with proxy_fcgi you will see no progress, but complete >>> output at once. >>> >>> mod_proxy knows about worker parameter flushpackets, but the docs say >>> this is in effect only for AJP. I can confirm that this and related options >>> have no effect. >>> There are some workarounds posted in the web, but only one worked for >>> me. If i add following line to the script, i also see a progress with >>> proxy_fcgi in browser: >>> >>> header('Content-Encoding: none'); >>> >>> Somebody knows a working workaround which works without scriptediting? >>> some workarounds tell about using "SetEnv no-gzip 1". This was not working >>> for me and iam not please to disable content-compression. >>> Is it planned to support >>flushpackets<< also to proxy_fcgi? >>> >>> May be this is not important for typical website but some >>> service/monitoring scripts. >>> >>> >> The functionality is committed to trunk but never backported to 2.4.x >> because I was not sure about its importance, it looks like some users might >> benefit from it :) >> >> The trunk patch is http://svn.apache.org/r1802040, it should apply to >> 2.4.x if you want to test it and give me some feedback. >> >> Thanks! >> >> I tried this and it works great. I see same behaviour as expected with >> other methods. I think some users might benefit from this. I saw some >> discussion related to this topic and people just ended up by ungainly >> workaround. >> Great news! >> >> Unfortunately i spoke too soon. I was too euphoric when reading your >> answer ;) >> Behaviour is definitively more then expected, but it seems there is still >> a minimum-limit for the buffer to flush. I suppose this limit is 4096 bytes. >> you can comprehend this with pastebinexample above. >> Change line 2 from "$string_length = 14096;" to "$string_length = 1331;" >> When calling this php-file you will see no progress. All output appears >> at once. >> Change scriptline to "$string_length = 1332;", you will see at least 2 >> steps of output, because first step seems to break this 4096 bufferlimit. >> increasing $string_length more and more results in more steps of output. >> So current mod_proxy_fcgi.c from svn with configured "flushpackets=On" >> seems to work exaktly like "flushpackets=auto iobuffersize=4096". >> setting iobuffersize to lower numbers has no effect. >> What do you think? Is there still a hard-coded limit or do i have a >> problem in my configuration? >> I would be really glad, if you could take a look at this issue. >> > > I am far from being an expert in PHP, but I added "ob_flush();" right > before "flush()" in your script and the 1331 use case seems flushing > correctly. Do you mind to check and let me know what do you get on your > testing environment? As far as I can see in the mod_proxy_fcgi's code the > iobuffersize variable is taken into account.. > > It seems that i was additional mocked by my browser. There is no need to > edit this script, just using the right browser ;) > I think your new mod_proxy_fcgi.c did it and my testing was incorrect. I > think we can go into weekend.. >
Full list of commits is: svn merge -c 1802040,1807876,1808014,1805490 ^/httpd/httpd/trunk . mod_proxy_fcgi.c only patch: http://people.apache.org/~elukey/httpd_2.4.x-mod_proxy_fcgi-force_flush.patch If you want to give it another round of test it would be really appreciated, in case everything is fine I'll propose it for backport to 2.4.x :) Luca
