Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 2B1F4200C0F for ; Thu, 2 Feb 2017 10:15:03 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 29BFA160B54; Thu, 2 Feb 2017 09:15:03 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 251E5160B57 for ; Thu, 2 Feb 2017 10:15:00 +0100 (CET) Received: (qmail 59061 invoked by uid 500); 2 Feb 2017 09:14:58 -0000 Mailing-List: contact dev-help@hc.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "HttpComponents Project" Delivered-To: mailing list dev@hc.apache.org Received: (qmail 59050 invoked by uid 99); 2 Feb 2017 09:14:58 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Feb 2017 09:14:58 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 3A340C0258 for ; Thu, 2 Feb 2017 09:14:58 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, KAM_LAZY_DOMAIN_SECURITY=1, RP_MATCHES_RCVD=-2.999] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id s6MPmadSQqr5 for ; Thu, 2 Feb 2017 09:14:57 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id A05705FDC1 for ; Thu, 2 Feb 2017 09:14:56 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 94439E02A9 for ; Thu, 2 Feb 2017 09:14:55 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 0F3B62528A for ; Thu, 2 Feb 2017 09:14:54 +0000 (UTC) Date: Thu, 2 Feb 2017 09:14:54 +0000 (UTC) From: "Oleg Kalnichevski (JIRA)" To: dev@hc.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HTTPCORE-444) When using HTTPS server with NoConnectionReuseStrategy, connections are not closed MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Thu, 02 Feb 2017 09:15:03 -0000 [ https://issues.apache.org/jira/browse/HTTPCORE-444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15849689#comment-15849689 ] Oleg Kalnichevski commented on HTTPCORE-444: -------------------------------------------- Isaac, From the HTTP protocol standpoint there is no difference between plain connections or those with a transport security. The underlying transport security layer should have no bearing on HTTP connection persisitence of what so ever. What is different however is that termination of TLS secured connections involves a handshake on the TLS level prior to connection termination on the TCP/IP level. That basically means that TLS connections usually do not terminate immediately. If anything goes wrong during the final TLS handshake the connection can stay alive for some while (depending on many factors such as socket timeout and so on). So, at the moment I see no evidence of this being a defect in HttpCore. Oleg > When using HTTPS server with NoConnectionReuseStrategy, connections are not closed > ---------------------------------------------------------------------------------- > > Key: HTTPCORE-444 > URL: https://issues.apache.org/jira/browse/HTTPCORE-444 > Project: HttpComponents HttpCore > Issue Type: Bug > Components: HttpCore NIO > Affects Versions: 4.4.6 > Reporter: Isaac Cruz Ballesteros > Priority: Minor > > I have a HTTPS server using NIO, and configured with NoConnectionReuseStrategy so that connections are immediately closed after download. I'm extending AbstractHttpEntity and implementing HttpAsyncContentProducer to produce the content which will be sent in response to a GET. When all the content has been written in produceContent(), I call encoder.complete(). Basically a basic HTTPS server handling file downloads. > When using plain HTTP, after all data has been sent, ConnectionReuseStrategy,keepAlive() gets called, it returns false and the connection is closed immediately from the server. > But when using HTTPS, keepAlive() is called but it does not close the connection. I have been following the code from that point, setting a breakpoint in keepAlive(), and I have the impression that a new handshake is initiated (not 100% sure of this), sending some extra data which causes the client to send a RST instead of a FIN when closing connection. -- This message was sent by Atlassian JIRA (v6.3.15#6346) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org For additional commands, e-mail: dev-help@hc.apache.org