httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <stefan.eiss...@greenbytes.de>
Subject Re: socket timeouts
Date Thu, 21 Jan 2016 10:52:27 GMT
However seems to do it. Anyone for/against applying it?

===================================================================
--- modules/ssl/ssl_engine_io.c	(revision 1725894)
+++ modules/ssl/ssl_engine_io.c	(working copy)
@@ -506,6 +506,12 @@
             return -1;
         }
 
+        if (block == APR_BLOCK_READ 
+            && APR_STATUS_IS_TIMEUP(inctx->rc)
+            && APR_BRIGADE_EMPTY(inctx->bb)) {
+            /* don't give up, just return the timeout */
+            return -1;
+        }
         if (inctx->rc != APR_SUCCESS) {
             /* Unexpected errors discard the brigade */

> Am 20.01.2016 um 21:50 schrieb Yann Ylavic <ylavic.dev@gmail.com>:
> 
> On Tue, Jan 19, 2016 at 4:52 PM, Stefan Eissing
> <stefan.eissing@greenbytes.de> wrote:
>> 
>> I experimented with setting socket timeouts to 1 second during
>> HTTP/2's keepalive reading and closing the connection after n such
>> TIMEUP returns. That works nicely on cleartext connections, but
>> https:// return APR_EOF on reads after the first APR_ETIMEUP. Am I
>> seeing ghosts or is that something in SSL that regards timed-out
>> reads as basically broken?
> 
> Maybe mod_ssl could preserve downstream status when it's already an error?
> 
> Index: modules/ssl/ssl_engine_io.c
> ===================================================================
> --- modules/ssl/ssl_engine_io.c    (revision 1725250)
> +++ modules/ssl/ssl_engine_io.c    (working copy)
> @@ -679,7 +679,7 @@ static apr_status_t ssl_io_input_read(bio_filter_i
>                 if (*len > 0) {
>                     inctx->rc = APR_SUCCESS;
>                 }
> -                else {
> +                else if (inctx->rc == APR_SUCCESS) {
>                     inctx->rc = APR_EOF;
>                 }
>                 break;
> --


Mime
View raw message