> Thanks for testing!
And investigating the bug, nice report.
Hi Adam,
On Mon, Nov 2, 2020 at 1:04 PM Adam Hill wrote:
>
> Yep, I can confirm that the patch fixes the issue.
Thanks for testing, committed to trunk in https://svn.apache.org/r1883097
I'll propose a backport to 2.4.x ASAP.
> Interestingly ( or maybe not ) I had a quick glance at
On Sat, Oct 31, 2020 at 01:57:08AM +0100, Yann Ylavic wrote:
> On Wed, Oct 28, 2020 at 6:40 PM Joe Orton wrote:
> >
> > On Wed, Oct 21, 2020 at 05:17:01PM +0100, Adam Hill wrote:
> > > On Linux at least, you can see how much unsent data remains by querying
> > > the
> > > SIOCOUTQ ioctl, so the
Hi Yann,
Yep, I can confirm that the patch fixes the issue. Interestingly ( or maybe
not ) I had a quick glance at apr_socket_close and it seems to set a
SO_LINGER timeout of 30 seconds, so I sort of expected the problem still to
happen but at half the transfer rate but that doesn't seem to
On Wed, Oct 28, 2020 at 6:40 PM Joe Orton wrote:
>
> On Wed, Oct 21, 2020 at 05:17:01PM +0100, Adam Hill wrote:
> > On Linux at least, you can see how much unsent data remains by querying the
> > SIOCOUTQ ioctl, so the mitigation would be to check to see that ANY data
> > was draining at all, and
On Wed, Oct 21, 2020 at 05:17:01PM +0100, Adam Hill wrote:
> On Linux at least, you can see how much unsent data remains by querying the
> SIOCOUTQ ioctl, so the mitigation would be to check to see that ANY data
> was draining at all, and if so ( and there's some left ) extend the
> lingering
I've come across a situation whereby file transfers consistently fail from
an httpd server. On the one hand it's a bit of an edge case, but on the
other it definitely seems to be incorrect behaviour. I'm sure this must
have been discussed before, but I couldn't find anything much on the list
with
