Am 08.02.2018 um 19:33 schrieb Luca Toscano:

2018-02-02 12:20 GMT+01:00 Hajo Locke <hajo.lo...@gmx.de <mailto: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:

            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

            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.

        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
    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?



Reply via email to