httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hajo Locke <Hajo.Lo...@gmx.de>
Subject Re: [users@httpd] proxy_fcgi - force flush to client
Date Mon, 19 Feb 2018 09:11:51 GMT
Hello,

Am 08.02.2018 um 19:33 schrieb Luca Toscano:
>
>
> 2018-02-02 12:20 GMT+01:00 Hajo Locke <Hajo.Locke@gmx.de 
> <mailto:Hajo.Locke@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.Locke@gmx.de
>>     <mailto:Hajo.Locke@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.Locke@gmx.de
>>>>         <mailto:Hajo.Locke@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
>>>>         <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 
> <http://people.apache.org/%7Eelukey/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?
>
> Luca
>

Hajo

Mime
View raw message