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.

    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 =
    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
    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...



Reply via email to