You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Hajo Locke <Ha...@gmx.de> on 2018/01/31 09:27:27 UTC
[users@httpd] proxy_fcgi - force flush to client
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.
Thank you,
Hajo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] proxy_fcgi - force flush to client
Posted by Luca Toscano <to...@gmail.com>.
2018-02-19 12:07 GMT+01:00 Hajo Locke <Ha...@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 <Ha...@gmx.de>:
>
>>
>>
>> Am 02.02.2018 um 07:05 schrieb Luca Toscano:
>>
>> Hello Hajo,
>>
>> 2018-02-01 13:20 GMT+01:00 Hajo Locke <Ha...@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 <Ha...@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
Re: [users@httpd] proxy_fcgi - force flush to client
Posted by Hajo Locke <Ha...@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.Locke@gmx.de
>> <ma...@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
>>> <ma...@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
>>>>> <ma...@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?
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.
>>
>> Luca
>>
>
> Hajo
Thanks,
Hajo
Re: [users@httpd] proxy_fcgi - force flush to client
Posted by Hajo Locke <Ha...@gmx.de>.
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
> <ma...@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
>> <ma...@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
>>>> <ma...@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
Re: [users@httpd] proxy_fcgi - force flush to client
Posted by Luca Toscano <to...@gmail.com>.
2018-02-02 12:20 GMT+01:00 Hajo Locke <Ha...@gmx.de>:
>
>
> Am 02.02.2018 um 07:05 schrieb Luca Toscano:
>
> Hello Hajo,
>
> 2018-02-01 13:20 GMT+01:00 Hajo Locke <Ha...@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 <Ha...@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
Re: [users@httpd] proxy_fcgi - force flush to client
Posted by Hajo Locke <Ha...@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
> <ma...@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
>>> <ma...@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...
>
> Luca
>
Thanks,
Hajo
Re: [users@httpd] proxy_fcgi - force flush to client
Posted by Luca Toscano <to...@gmail.com>.
Hello Hajo,
2018-02-01 13:20 GMT+01:00 Hajo Locke <Ha...@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 <Ha...@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..
Luca
Re: [users@httpd] proxy_fcgi - force flush to client
Posted by Hajo Locke <Ha...@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
>> <ma...@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.
>>
>> Luca
>>
Thank you,
Hajo
Re: [users@httpd] proxy_fcgi - force flush to client
Posted by Hajo Locke <Ha...@gmx.de>.
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
> <ma...@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!
>
> Luca
>
Thanks,
Hajo
Re: [users@httpd] proxy_fcgi - force flush to client
Posted by Luca Toscano <to...@gmail.com>.
Hi Hajo,
2018-01-31 1:27 GMT-08:00 Hajo Locke <Ha...@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!
Luca