From harmony-dev-return-8102-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org Thu Jun 01 10:51:18 2006 Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 57640 invoked from network); 1 Jun 2006 10:51:17 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 1 Jun 2006 10:51:17 -0000 Received: (qmail 99989 invoked by uid 500); 1 Jun 2006 10:51:13 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 99791 invoked by uid 500); 1 Jun 2006 10:51:12 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 99777 invoked by uid 99); 1 Jun 2006 10:51:12 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Jun 2006 03:51:12 -0700 X-ASF-Spam-Status: No, hits=1.4 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: 202.81.18.155 is neither permitted nor denied by domain of paulex.yang@gmail.com) Received: from [202.81.18.155] (HELO ausmtp06.au.ibm.com) (202.81.18.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Jun 2006 03:51:10 -0700 Received: from sd0109e.au.ibm.com (d23rh905.au.ibm.com [202.81.18.225]) by ausmtp06.au.ibm.com (8.13.6/8.13.6) with ESMTP id k51Aqvjg6082750 for ; Thu, 1 Jun 2006 20:52:57 +1000 Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.250.237]) by sd0109e.au.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k51As74e106252 for ; Thu, 1 Jun 2006 20:54:07 +1000 Received: from d23av04.au.ibm.com (loopback [127.0.0.1]) by d23av04.au.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k51AoUfl028773 for ; Thu, 1 Jun 2006 20:50:30 +1000 Received: from d23m0011.cn.ibm.com (d23m0011.cn.ibm.com [9.181.32.74]) by d23av04.au.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k51AoTGB028473 for ; Thu, 1 Jun 2006 20:50:29 +1000 Received: from [127.0.0.1] ([9.181.107.157]) by d23m0011.cn.ibm.com (Lotus Domino Release 6.5.5HF262) with ESMTP id 2006060118501798-5303 ; Thu, 1 Jun 2006 18:50:17 +0800 Message-ID: <447EC664.6080801@gmail.com> Date: Thu, 01 Jun 2006 18:50:12 +0800 From: Paulex Yang User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: harmony-dev@incubator.apache.org Subject: Re: [jira] Commented: (HARMONY-499) Java 5 Enhancement: java.net.HttpURLConnection should send request head with a connection-field of "Keep-Alive" References: <7124894.1149140250844.JavaMail.jira@brutus> <447E9E8E.2010105@gmail.com> In-Reply-To: X-MIMETrack: Itemize by SMTP Server on D23M0011/23/M/IBM(Release 6.5.5HF262 | April 5, 2006) at 01/06/2006 18:50:17, Serialize by Router on D23M0011/23/M/IBM(Release 6.5.5HF262 | April 5, 2006) at 01/06/2006 18:50:29, Serialize complete at 01/06/2006 18:50:29 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Alexander, Please see my comments below. Alexander Kleymenov wrote: > Paulex, > > I make HttpsURLConnection as a wrapper over the existing > HttpURLConnection > implementation > (due to HTTPs spec: > "Simply use HTTP over TLS > precisely as you would use HTTP over TCP." RFC 2818). > I.e. I do not reimplement HTTP functionality, just reuse it (although > some > minor updates of the base HttpURLConnection implementation should be > made). > So if there will be support for persistent connections in > HttpURLConnection, > HttpsURLConnection will have it too. I don't catch up, based on above, may I assume that your HttpsURLConnection implementation is neutral to HttpURLConnection whatever we have persistent connection support or not? If so, then the cached socket can be shared between Https and Http, because the SSL related work is handled over the HttpURLConnection's plain socket. If not, then the HttpsURLConnection won't automatically share persistent connections if HttpURLConnection does. > But Http implementation uses plain > sockets, while Https uses SSL sockets. Thus we should use whether 2 > different connection pools (one for http, one for https) or indexing of > sockets in the pool should be made by URL with non empty protocol part > (i.e. > "http://some.host/" or "https://some.host/") to distinguish http > connections > from https' ones. This issue is just what we should discuss here, IIUI, the SSLSocket is based on plain Socket, too, and it is created by SSLSocketFactory.createSocket(Socket....), so we have several options here: 1. cache plain socket and ssl socket in different pool by same mechanism 2. cache them in same pool with different index (IMO it has no significant difference with 1) 3. cache plain socket only, and create ssl socket over them on demand 4. handle ssl issue over the HttpURLConnection, so that HttpsURLConnection don't need to care about the persistent issues (as you said above) I'm sure you have more authority on SSL layer issue than me, so would you please help to evaluate the feasibility and performance impact of the above? > > Thanks, > Alexander > -- Paulex Yang China Software Development Lab IBM --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org For additional commands, e-mail: harmony-dev-help@incubator.apache.org