Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
MIME-Version: 1.0
In-Reply-To: <CAKQ1sVOM6=xe8t+uHzVw0AK+O6zzrHst99u7HQvag_76PuYjfg@mail.gmail.com>
References: <bug-56188-7868@https.bz.apache.org/bugzilla/> <bug-56188-7868-OpEhF5VkFj@https.bz.apache.org/bugzilla/>
 <CAKQ1sVP90RsdL8VgijqDvRoJpfxdtj+7Bv40qPTw_ZDsoZNDfA@mail.gmail.com>
 <CAFedD43D0jB-TF8H9PazkSiPjD6iqQ5q5gLBRbq2d=vYbeq_7A@mail.gmail.com> <CAKQ1sVOM6=xe8t+uHzVw0AK+O6zzrHst99u7HQvag_76PuYjfg@mail.gmail.com>
From: Luca Toscano <toscano.luca@gmail.com>
Date: Thu, 2 Feb 2017 16:51:24 +0100
Message-ID: <CAFedD42AmwPf8KiEVox1mgPPtzY3CkVWADuygo_doMtz0rWh0A@mail.gmail.com>
Subject: Re: [Bug 56188] mod_proxy_fcgi does not send FCGI_ABORT_REQUEST on
 client disconnect
To: Apache HTTP Server Development List <dev@httpd.apache.org>
Content-Type: multipart/alternative; boundary=f403045f200e3298e505478e23ab
archived-at: Thu, 02 Feb 2017 15:51:33 -0000

--f403045f200e3298e505478e23ab
Content-Type: text/plain; charset=UTF-8

2017-01-30 21:58 GMT+01:00 Yann Ylavic <ylavic.dev@gmail.com>:

> On Mon, Jan 30, 2017 at 7:17 PM, Luca Toscano <toscano.luca@gmail.com>
> wrote:
> >
> > The use case that I had (the one that caused me to check the original
> > bugzilla task/patch and work on it) was a long running PHP script
> (running
> > on HHVM) that wasn't returning anything until the end of the job
> (minutes),
> > causing mod-proxy-fcgi to keep waiting even if the client disconnected.
> In
> > the beginning I also thought that there was a way to "signal" the FCGI
> > backend to stop whatever was doing (FCGI_ABORT), but it turned out to be
> not
> > widely implemented (at least from what I have checked, more info in
> > bugzilla). Timeout and ProxyTimeout could be a good compromise for this
> > particular issue, but it is a "one size fits all" solution that some
> users
> > didn't like (providing a patch with the pollset solution).
>
> I think that's what CGIDScriptTimeout or ProxyTimeout are for: avoid
> waiting too much for the script or backend (above some reasonably
> configured limit).
>
> >
> > If we remove the above use case (I fixed it in my Production environment
> > with a long Timeout value), would it be fine to rely on something like
> the
> > conn->aborted flag (afaics set by the output filter's chain while
> writing to
> > the client's conn)? It would simplify a lot the problem :)
>
> AFAICT, if forwarding data to the client fails (e.g. socket
> disconnected), ap_pass_brigade() returns an error and the loop exits.
>

Yes confirmed with a test (that flushes data to output periodically), the
connection->aborted flag is set and mod_proxy_fcgi behaves correctly.


> Maybe what is missing is nonblocking reads on the backend side, and on
> EAGAIN flush on the client side to detect potential socket errors?
>

Interesting.. So the idea would be to be non blocking while reading from
the FCGI backend, and in case of EAGAIN flush to the client in order to
force ap_pass_brigade to detect if the client aborted the connection. The
flushing part might be tricky to implement (at least for me, but I'll try
to work on it :).

In any case, it seems like we are in agreement to discard the client
connection polling idea (if anybody has more thoughts please speak up). In
any case, I believe that this use case would need to be documented properly
in the docs to warn users assuming that FCGI_ABORT is implemented.

Thanks for the review!

Luca

--f403045f200e3298e505478e23ab
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">2017-01-30 21:58 GMT+01:00 Yann Ylavic <span dir=3D"ltr">&lt;<a href=3D=
"mailto:ylavic.dev@gmail.com" target=3D"_blank">ylavic.dev@gmail.com</a>&gt=
;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Mon, Jan 30=
, 2017 at 7:17 PM, Luca Toscano &lt;<a href=3D"mailto:toscano.luca@gmail.co=
m">toscano.luca@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; The use case that I had (the one that caused me to check the original<=
br>
&gt; bugzilla task/patch and work on it) was a long running PHP script (run=
ning<br>
&gt; on HHVM) that wasn&#39;t returning anything until the end of the job (=
minutes),<br>
&gt; causing mod-proxy-fcgi to keep waiting even if the client disconnected=
. In<br>
&gt; the beginning I also thought that there was a way to &quot;signal&quot=
; the FCGI<br>
&gt; backend to stop whatever was doing (FCGI_ABORT), but it turned out to =
be not<br>
&gt; widely implemented (at least from what I have checked, more info in<br=
>
&gt; bugzilla). Timeout and ProxyTimeout could be a good compromise for thi=
s<br>
&gt; particular issue, but it is a &quot;one size fits all&quot; solution t=
hat some users<br>
&gt; didn&#39;t like (providing a patch with the pollset solution).<br>
<br>
</span>I think that&#39;s what CGIDScriptTimeout or ProxyTimeout are for: a=
void<br>
waiting too much for the script or backend (above some reasonably<br>
configured limit).<br>
<span class=3D""><br>
&gt;<br>
&gt; If we remove the above use case (I fixed it in my Production environme=
nt<br>
&gt; with a long Timeout value), would it be fine to rely on something like=
 the<br>
&gt; conn-&gt;aborted flag (afaics set by the output filter&#39;s chain whi=
le writing to<br>
&gt; the client&#39;s conn)? It would simplify a lot the problem :)<br>
<br>
</span>AFAICT, if forwarding data to the client fails (e.g. socket<br>
disconnected), ap_pass_brigade() returns an error and the loop exits.<br></=
blockquote><div><br></div><div>Yes confirmed with a test (that flushes data=
 to output periodically), the connection-&gt;aborted flag is set and mod_pr=
oxy_fcgi behaves correctly.</div><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">
Maybe what is missing is nonblocking reads on the backend side, and on<br>
EAGAIN flush on the client side to detect potential socket errors?<br></blo=
ckquote><div><br></div><div>Interesting.. So the idea would be to be non bl=
ocking while reading from the FCGI backend, and in case of EAGAIN flush to =
the client in order to force ap_pass_brigade to detect if the client aborte=
d the connection. The flushing part might be tricky to implement (at least =
for me, but I&#39;ll try to work on it :).</div><div><br></div><div>In any =
case, it seems like we are in agreement to discard the client connection po=
lling idea (if anybody has more thoughts please speak up). In any case, I b=
elieve that this use case would need to be documented properly in the docs =
to warn users assuming that FCGI_ABORT is implemented.</div><div><br></div>=
<div>Thanks for the review!</div><div><br></div><div>Luca</div></div><br></=
div></div>

--f403045f200e3298e505478e23ab--