httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <rpl...@apache.org>
Subject Re: svn commit: r1705236 - /httpd/httpd/trunk/modules/ssl/ssl_engine_io.c
Date Fri, 25 Sep 2015 08:01:30 GMT


On 09/25/2015 09:27 AM, ylavic@apache.org wrote:
> Author: ylavic
> Date: Fri Sep 25 07:27:04 2015
> New Revision: 1705236
> 
> URL: http://svn.apache.org/viewvc?rev=1705236&view=rev
> Log:
> mod_ssl: don't FLUSH first for non blocking reads.
> Such readers are prepared to received empty data anyway (and take appropriate
> action), while e.g. check_pipeline() is not expecting the pipe to be flushed
> under it.
> 
> Modified:
>     httpd/httpd/trunk/modules/ssl/ssl_engine_io.c
> 
> Modified: httpd/httpd/trunk/modules/ssl/ssl_engine_io.c
> URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_io.c?rev=1705236&r1=1705235&r2=1705236&view=diff
> ==============================================================================
> --- httpd/httpd/trunk/modules/ssl/ssl_engine_io.c (original)
> +++ httpd/httpd/trunk/modules/ssl/ssl_engine_io.c Fri Sep 25 07:27:04 2015
> @@ -472,9 +472,12 @@ static int bio_filter_in_read(BIO *bio,
>       * connection or for a proxy connection.  Calling _out_flush
>       * should be very cheap in cases where it is unnecessary (and no
>       * output is buffered) so the performance impact of doing it
> -     * unconditionally should be minimal.
> +     * unconditionally should be minimal, but in non blocking mode
> +     * where the caller may not expect the flush round trip (e.g.
> +     * check_pipeline()'s speculative and non-blocking read).
>       */
> -    if (bio_filter_out_flush(inctx->bio_out) < 0) {
> +    if (block != APR_NONBLOCK_READ &&
> +            bio_filter_out_flush(inctx->bio_out) < 0) {
>          bio_filter_out_ctx_t *outctx = inctx->bio_out->ptr;
>          inctx->rc = outctx->rc;
>          return -1;
> 
> 
> 

Can't we run in endless loops here, because no new input will arrive until the output buffer
was flushed (e.g. due to
pending SSL layer data the client is waiting for before it sents new data)? Or do you expect
the non blocking readers
to switch to blocking next time they read?

Regards

RĂ¼diger



Mime
View raw message