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 11:07:50 GMT
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 
>> <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?
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

Mime
View raw message