From users-return-116890-archive-asf-public=cust-asf.ponee.io@httpd.apache.org Thu Feb 1 13:21:10 2018 Return-Path: X-Original-To: archive-asf-public@eu.ponee.io Delivered-To: archive-asf-public@eu.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by mx-eu-01.ponee.io (Postfix) with ESMTP id 9781A180652 for ; Thu, 1 Feb 2018 13:21:10 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 87C16160C44; Thu, 1 Feb 2018 12:21:10 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 85DBE160C26 for ; Thu, 1 Feb 2018 13:21:09 +0100 (CET) Received: (qmail 87375 invoked by uid 500); 1 Feb 2018 12:21:03 -0000 Mailing-List: contact users-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: users@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@httpd.apache.org Received: (qmail 87365 invoked by uid 99); 1 Feb 2018 12:21:03 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Feb 2018 12:21:03 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id DE295C05E3 for ; Thu, 1 Feb 2018 12:21:02 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.279 X-Spam-Level: * X-Spam-Status: No, score=1.279 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=2, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id f4dS-Oaa7UOr for ; Thu, 1 Feb 2018 12:21:00 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 236795F1EE for ; Thu, 1 Feb 2018 12:21:00 +0000 (UTC) Received: from [192.168.6.96] ([85.13.159.249]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M7ojs-1eue740Oxc-00vNFm for ; Thu, 01 Feb 2018 13:20:54 +0100 To: users@httpd.apache.org References: From: Hajo Locke Message-ID: <4cd09775-4a6f-282d-1234-7dd56e24cc4e@gmx.de> Date: Thu, 1 Feb 2018 13:20:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1F0CF5A49BC157A00C09F1E0" Content-Language: de-DE X-Provags-ID: V03:K0:DlFIN6lN8CHNUViTAJj2Q4afnBWdCs7z8Rg8ThKRHzlTAv76xps dv3i22cGZW4rkElQH6fw0nv9Wt2ELb15P+KmddgJX7QTXp7uIvDxsPj0v0lMRrJvHUmEHDD cTz1PfMSheFIwy7CJLgWZR4GSJ+caGRizqirxcpLlIoNoSaOvktVq30/S7WGDw1ueVAqeOs vFvLZt466TF/LzQIbW/Tg== X-UI-Out-Filterresults: notjunk:1;V01:K0:SDIEtJoRjbk=:24yFXUqscReD4Fetwl8J58 4QRVlsEVHq7Kil5fwWFLrrjAThQQ1q+22FD6bBtPsIapdwsZA+2LOuSXSYfW7+LM0PU/CZru4 KZOb69Xn+Ux+rjHAjuzWsqgTAJHM1GO5jMBF6PFhmhAz24Dd/UmvozhGSjuLVraV/kaz0U05Y kNhXXCabw0RUYt935MscVW7rDSFATtjdW/doMEkAfYCUXgqjc4M2wLRmfHJvQXRmzmKsk2v+A k9BrkpAqpaHDjeKwPrcVKkgTGW+PRp7CClhODxgeXFbhj/j0wXz8qVGmKXWbjTFrPZlrEw9bI sKL8lIbTKOnAMRG7SUEE4lLppbLJzPeYhD5uEBYtjnZr1khGzOBWC5Lku5KKE95H1Ssul4Zb6 pb45nT3qOjYViCh1zTr8Yogmqlgf91VrngNWISqohZy1qrz9/UWhPOhmSDckVsI7S40TDdpxc dBGFt1A9Au1S2CWYfFkna0Wc3etbSiJtrZ16qMpyodTyckgsIXMM+EXVgXienPa6WoNQoPPAi Db+ELINwSaizugWApLFUzA1qNea+vrcXIx1uVwE8GGlqk6RI7a3M+ceJqNl9K6nq3MnpiKfVy 54+NWG39ny46Zosy7IPNiyExtLPfwUoGXbXBag0rltMP0kDgfPINnNqDz9ct2COhdlNResH1p TMvIcgOAaJR7iere0ouo9Zcu0utJ9UwTD4IrbXHrTuXvxiGy8tm1V/Cglhez1gaJjXwTHXm2B zw9qZ2xlmmsfUE6Y94E9GSTddovG2b+y3ua4z6r0x2nV+J2FqzqDpSlCU3kcVWcm+Sw/gviUZ Ci+x7jzm6mpQPTC6RjGKIvXOZkrph9x3esplRepzYAS2PVFmig= Subject: Re: [users@httpd] proxy_fcgi - force flush to client --------------1F0CF5A49BC157A00C09F1E0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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: >> 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 --------------1F0CF5A49BC157A00C09F1E0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 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>:
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

--------------1F0CF5A49BC157A00C09F1E0--