harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Kleymenov" <kleyme...@gmail.com>
Subject Re: [jira] Commented: (HARMONY-499) Java 5 Enhancement: java.net.HttpURLConnection should send request head with a connection-field of "Keep-Alive"
Date Fri, 02 Jun 2006 08:26:29 GMT

On 6/1/06, Paulex Yang <paulex.yang@gmail.com> wrote:
> > 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

I extended existing o.a.h...HttpUC implementation with o.a.h...HttpsUC
and redefine HttpUC.connect method to use SSLSocket instead of plain

>, based on above, may I assume that your
> HttpsURLConnection implementation is neutral to HttpURLConnection
> whatever we have persistent connection support or not?

It depends on how persistent connections support will be implemented.
It can be implemented in such a way that o.a.h...HttpsUC
implementation could be neutral. For example:

HttpUC.connect() {
      Socket s = getFromPool(url); // url contains http: or https:
      If (s == null) {
            s = new Socket();
            s = wrapConnectedSocket(s);
            putIntoThePool(url, s);

In such a way, HttpsUC should only redefine method
wrapConnectedSocket() which will create SSLSocket over the connected
plain socket. It will be stored (as SSLSocket) in the pool by HttpUC
and HttpsUC will not realize it. In other words HttpsUC could be made
in such a way that it will be independent of HttpUC implementation.
All it will do is wrapping the plain connected socket into the SSL

There is one issue with this approach. If HttpsUC uses a proxy the
first interaction over the socket (sending the CONNECT request to the
proxy, and receiving the response) should be made in plain format and
then socket should be wrapped into the SSLSocket (and stored in the
pool). So wrapConnectedSocket() method call and putting resulted
socket in the pool can be delayed in the case of proxy connection.

> 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)

The first variant seems to have better performance, but we should analyze it.

> 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)

We can not mix up SSL sockets with plain ones. HttpUC should not reuse
socket created by HttpsUC because server side will expect encrypted
data on SSL connections and will fail if receive plain text (sent by
Persistent connection mechanism should be implemented in HttpUC in
such a way that it could store SSL and plain sockets and distinguish

> 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?

I think we should follow 1st or 2nd variant which are practically the
same in sense of implementation.

Thank You,

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

View raw message