2018-02-19 12:07 GMT+01:00 Hajo Locke <hajo.lo...@gmx.de>: > Hello, > > > Am 19.02.2018 um 10:11 schrieb Hajo Locke: > > Hello, > > Am 08.02.2018 um 19:33 schrieb Luca Toscano: > > > > 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 :) > > sorry for late reply, was in the clinch with special kind of the flu and > still not over. > i applied patch to current 2.4.29 sources and can confirm it works, but > there is a little constraint. > It only works, when using ob_flush() in script: > https://pastebin.com/DVFzCBAc > with mod_php or classical mod_fastcgi it works in script by just using > flush(). so in example script lines 3,7,17 are not necessary > Is this proxy dependent? > > it is working now. did some changes to php-configuration and dont see any > differences any more. httpd_2.4.x-mod_proxy_fcgi-force_flush.patch > <http://people.apache.org/%7Eelukey/httpd_2.4.x-mod_proxy_fcgi-force_flush.patch> > is working. > Thanks Luca. From my side i would be happy to have this patch in next > official release. >
Change accepted, it will be part of 2.4.31 :) Luca
