httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hajo Locke <>
Subject Re: [users@httpd] proxy_fcgi - force flush to client
Date Fri, 02 Feb 2018 11:20:16 GMT

Am 02.02.2018 um 07:05 schrieb Luca Toscano:
> Hello Hajo,
> 2018-02-01 13:20 GMT+01:00 Hajo Locke < 
> <>>:
>     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 <
>>>     <>>:
>>>         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:
>>>         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
>>>     <>, 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

View raw message