Hello!

On Thu, Dec 19, 2019 at 09:01:10AM -0800, Maksim Yevmenkin wrote:

> hello,
>
> [...]
>
> > > > > 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.
>
> [...]
>
> > Not really. I meant the workaround in question won't work on
> > systems with kqueue. The problem itself is present with kqueue as
> > well.
>
> i suspect there is another instance of the same problem. it manifests
> itself when nginx is reading reueqst over https, i.e. ngx_ssl_recv()
> is interacting with ngx_http_process_request_line() and friends.
> rev->handler gets overwritten, and, ngx_ssl_next_read_handler() never
> gets called.

Yes, any change of connection read handlers can be problematic
here.

> i wonder if SSL_pending(3) can be of value here, i.e.

No, SSL_pending() only returns pending bytes from the SSL record
currently being parsed, and there can be additional records in SSL
library buffers even if SSL_pending() returns 0. Hence it is
useless.

The only working alternative solution I'm aware of is to use
BIO_set_callback() and count actual bytes read from the socket.
Unfortunately, BoringSSL removed BIO_set_callback(), making this
solution non-portable.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel