Fwd: 1.17.5 regression

[Gábor Boskovits]

Ok, thanks.

Maxim Dounin <mdounin at mdounin.ru> ezt írta (időpont: 2019. dec. 19., Csü
13:44):

> Hello!
>
> On Thu, Dec 19, 2019 at 11:45:28AM +0300, Ruslan Ermilov wrote:
>
> > On Wed, Dec 18, 2019 at 06:35:35PM +0100, Gábor Boskovits wrote:
> > > Hello Maxim,
> > >
> > > Maxim Dounin <mdounin at mdounin.ru> ezt írta (időpont: 2019. dec. 18.,
> > > Sze, 18:24):
> > > >
> > > > Hello!
> > > >
> > > > On Mon, Dec 16, 2019 at 03:02:37PM +0100, Gábor Boskovits wrote:
> > > >
> > > > > On berlin.guix.gnu.org we observed a regression upon upgrading
> nginx
> > > > > to 1.17.5. The problem was, when pipelining request to a proxy
> using
> > > > > tls, we suddenly started to get 408 client timeouts, manifesting in
> > > > > dropped connections. Currently we worked around the issue by
> > > > > downgrading to 1.17.4. I have collected some information about the
> > > > > problem here:
> > > > > https://gitlab.com/g_bor/fix-nginx-tls
> > > > > It contains the logs from the good and the bad version, a full
> nginx
> > > > > config, some info about how nginx was built. I managed to bisect
> the
> > > > > problem down to changeset 9d2ad2fb4423, which introduced the
> problem.
> > > > > Any help in further debuggin this would be greatly appreciated.
> > > >
> > > > Thanks for the report, it indeed looks like a bug introduced
> > > > in 9d2ad2fb4423.
> > > >
> > > > The problem is that c->read->handler is overwritted when switching
> > > > to the next pipelined request, ngx_ssl_next_read_handler() is not
> > > > called, and c->read->ready remains not set.  I'll take a look how
> > > > to fix it properly.
> > >
> > > Thanks for having a look.
> > >
> > > Please keep me updated when the fix gets applied.
> > >
> > > >
> > > > Note well that a simpler workaround might be to build nginx with
> > > > the --with-cc-opt="-DNGX_HAVE_FIONREAD=0" configure argument, this
> > > > will disable the code in question on systems not using kqueue.
> > > >
> > >
> > > Thanks for the information, we do not yet support any systems with
> kqueue yet,
> > > so this might work temporarily.
> >
> > Maxim means e.g. Linux when he says "on systems not using kqueue".
> > There's no such problem on systems with kqueue, e.g. FreeBSD.
>
> Not really.  I meant the workaround in question won't work on
> systems with kqueue.  The problem itself is present with kqueue as
> well.
>
> That is, the workaround in question will work fine on Linux, but
> won't work on FreeBSD (unless you configure nginx to use select or
> poll, but probably this isn't a good idea).
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20191219/5988a2fb/attachment.htm>