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 BCE9A200C0F for ; Thu, 2 Feb 2017 12:38:01 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id BB76D160B61; Thu, 2 Feb 2017 11:38:01 +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 75547160B57 for ; Thu, 2 Feb 2017 12:38:00 +0100 (CET) Received: (qmail 12425 invoked by uid 500); 2 Feb 2017 11:37: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 12414 invoked by uid 99); 2 Feb 2017 11:37:58 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Feb 2017 11:37:58 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 4AE1CC11DB for ; Thu, 2 Feb 2017 11:37:58 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-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-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id FPmvuXAtdLja for ; Thu, 2 Feb 2017 11:37:56 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id C01CE5F3A1 for ; Thu, 2 Feb 2017 11:37:55 +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 E3F96E01D8 for ; Thu, 2 Feb 2017 11:37:54 +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 0504325286 for ; Thu, 2 Feb 2017 11:37:53 +0000 (UTC) Date: Thu, 2 Feb 2017 11:37:51 +0000 (UTC) From: "Isaac Cruz Ballesteros (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 11:38:01 -0000 [ https://issues.apache.org/jira/browse/HTTPCORE-444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15849815#comment-15849815 ] Isaac Cruz Ballesteros commented on HTTPCORE-444: ------------------------------------------------- Oleg, Thanks for your response, from this page: http://security.stackexchange.com/questions/82028/ssl-tls-is-a-server-always-required-to-respond-to-a-close-notify, in particular in the second answer: _When the application protocol that goes within the SSL/TLS tunnel is self-terminated, the close_notify is redundant, and can be dispensed with. Which is exactly what happens in modern HTTPS_. While I don't have a strong opinion on that, I have tested using HttpsUrlConnection from JDK and the connection is not closed until I call urlConnection.disconnect() (and thus closed by the client), which is not the case when using HTTP where the connection is closed immediately. This is also the case with a C client using libcurl. So I understand that the behavior of httpcore is 100% correct, but it seems the HTTPS clients I tried do not implement that close-notify, meaning that connections are left open until there's a timeout in either client or server. Isaac > 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