You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Richard Liang (JIRA)" <ji...@apache.org> on 2006/05/24 09:11:29 UTC
[jira] Created: (HARMONY-499) Java 5 Enhancement:
java.net.HttpURLConnection should send request head with a connection-field
of "Keep-Alive"
Java 5 Enhancement: java.net.HttpURLConnection should send request head with a connection-field of "Keep-Alive"
---------------------------------------------------------------------------------------------------------------
Key: HARMONY-499
URL: http://issues.apache.org/jira/browse/HARMONY-499
Project: Harmony
Type: Improvement
Components: Classlib
Reporter: Richard Liang
Priority: Minor
Hello,
java.net.HttpURLConnection should send request head with a default connection-field of "Keep-Alive". Currently in its implementation, it sends a connection-field of "close", but does not close its own socket after connection, which may cause low performance and strange behavior on some servers.
Best regards,
Richard
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-499) Java 5 Enhancement:
java.net.HttpURLConnection should send request head with a connection-field
of "Keep-Alive"
Posted by "Richard Liang (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-499?page=all ]
Richard Liang updated HARMONY-499:
----------------------------------
Attachment: luni.src.net.diff
Hello,
Would you please try the patch? Thanks a lot.
PS. I do not provide test for this issue because the test requires a http server. After "Jetty integration", I can attach patch for test case. :-)
Best regards,
Richard
> Java 5 Enhancement: java.net.HttpURLConnection should send request head with a connection-field of "Keep-Alive"
> ---------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-499
> URL: http://issues.apache.org/jira/browse/HARMONY-499
> Project: Harmony
> Type: Improvement
> Components: Classlib
> Reporter: Richard Liang
> Priority: Minor
> Attachments: luni.src.net.diff
>
> Hello,
> java.net.HttpURLConnection should send request head with a default connection-field of "Keep-Alive". Currently in its implementation, it sends a connection-field of "close", but does not close its own socket after connection, which may cause low performance and strange behavior on some servers.
> Best regards,
> Richard
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Commented: (HARMONY-499) Java 5 Enhancement: java.net.HttpURLConnection
should send request head with a connection-field of "Keep-Alive"
Posted by Paulex Yang <pa...@gmail.com>.
Richard Liang wrote:
> Hello Alexander,
>
> I agree that my implementation about "Connection: Keep-Alive" is
> incorrect. Thank you.
>
> And as mentioned in the spec of "Persistent Connections"[1]:
>
> .....
>
> /The support for HTTP keep-Alive is done transparently. However, it
> can be controlled by system properties http.keepAlive, and
> http.maxConnections, as well as by HTTP/1.1 specified request and
> response headers.
>
> The system properties that control the behavior of Keep-Alive are:
>
> http.keepAlive=<boolean>
> default: true
> Indicates if keep alive (persistent) connections should be supported.
>
> http.maxConnections=<int>
> default: 5
> Indicates the maximum number of connections per destination to be kept
> alive at any given time/
> .....
>
Seems at least we should read this properties at first and then
configure the http request head? I think this worths another patch for 499?
> So we SHALL provide some kind of cache mechanism to support Persistent
> Connections, would you mind raise a separate JIRA about this issue?
> Thanks a lot.
Agree, I had an incomplete discussion with Alexander a couple of weeks
ago, and it's time to resurrect the discussion again. I'll resume the
discussion in the other mail.
>
>
> 1.http://java.sun.com/j2se/1.5.0/docs/guide/net/http-keepalive.html
>
> Alexander Kleymenov (JIRA) wrote:
>> [
>> http://issues.apache.org/jira/browse/HARMONY-499?page=comments#action_12414202
>> ]
>> Alexander Kleymenov commented on HARMONY-499:
>> ---------------------------------------------
>>
>> Hello,
>>
>> I am working on HttpsURLConnection and noticed this JIRA report.
>>
>> I went through the Java 5 Enhancements for Networking and could not
>> found any statements for HttpURLConnection.
>> Then I examined the HTTP protocol specification (RFC 2616 can be
>> found at http://www.ietf.org/rfc/rfc2616.txt).
>> It says:
>> "HTTP/1.1 applications that do not support persistent connections
>> MUST
>> include the "close" connection option in every message."
>>
>> The source file of HttpURLConnection implementation does not seem to
>> support persistent connections.
>> So recent changes made to the class
>>
>> org.apache.harmony.luni.internal.net.www.protocol.http.HttpURLConnection
>>
>> ("Connection: close" --> "Connection: Keep-Alive") seem to be
>> incorrect without implementation of support for persistent connections.
>>
>> Thanks,
>> Alexander
>>
>>
>>> Java 5 Enhancement: java.net.HttpURLConnection should send request
>>> head with a connection-field of "Keep-Alive"
>>> ---------------------------------------------------------------------------------------------------------------
>>>
>>>
>>> Key: HARMONY-499
>>> URL: http://issues.apache.org/jira/browse/HARMONY-499
>>> Project: Harmony
>>> Type: Improvement
>>>
>>
>>
>>> Components: Classlib
>>> Reporter: Richard Liang
>>> Assignee: Tim Ellison
>>> Priority: Minor
>>> Attachments: luni.src.net.diff
>>>
>>> Hello,
>>> java.net.HttpURLConnection should send request head with a default
>>> connection-field of "Keep-Alive". Currently in its implementation,
>>> it sends a connection-field of "close", but does not close its own
>>> socket after connection, which may cause low performance and strange
>>> behavior on some servers.
>>> Best regards,
>>> Richard
>>>
>>
>>
>
--
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
Re: [jira] Commented: (HARMONY-499) Java 5 Enhancement: java.net.HttpURLConnection should send request head with a connection-field of "Keep-Alive"
Posted by Alexander Kleymenov <kl...@gmail.com>.
Hello Richard,
If we are going to implement persistent connections and make them
configurable we should fix this piece of code anyway. So it is not
necessary to roll back your fix.
I will file a JIRA about this issue.
Thank You,
Alexander
---------------------------------------------------------------------
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
Re: [jira] Commented: (HARMONY-499) Java 5 Enhancement: java.net.HttpURLConnection
should send request head with a connection-field of "Keep-Alive"
Posted by Richard Liang <ri...@gmail.com>.
Hello Alexander,
I agree that my implementation about "Connection: Keep-Alive" is
incorrect. Thank you.
And as mentioned in the spec of "Persistent Connections"[1]:
.....
/The support for HTTP keep-Alive is done transparently. However, it can
be controlled by system properties http.keepAlive, and
http.maxConnections, as well as by HTTP/1.1 specified request and
response headers.
The system properties that control the behavior of Keep-Alive are:
http.keepAlive=<boolean>
default: true
Indicates if keep alive (persistent) connections should be supported.
http.maxConnections=<int>
default: 5
Indicates the maximum number of connections per destination to be kept
alive at any given time/
.....
So we SHALL provide some kind of cache mechanism to support Persistent
Connections, would you mind raise a separate JIRA about this issue?
Thanks a lot.
1.http://java.sun.com/j2se/1.5.0/docs/guide/net/http-keepalive.html
Alexander Kleymenov (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/HARMONY-499?page=comments#action_12414202 ]
>
> Alexander Kleymenov commented on HARMONY-499:
> ---------------------------------------------
>
> Hello,
>
> I am working on HttpsURLConnection and noticed this JIRA report.
>
> I went through the Java 5 Enhancements for Networking and could not found any statements for HttpURLConnection.
>
> Then I examined the HTTP protocol specification
> (RFC 2616 can be found at http://www.ietf.org/rfc/rfc2616.txt).
> It says:
> "HTTP/1.1 applications that do not support persistent connections MUST
> include the "close" connection option in every message."
>
> The source file of HttpURLConnection implementation does not seem to support persistent connections.
>
> So recent changes made to the class
>
> org.apache.harmony.luni.internal.net.www.protocol.http.HttpURLConnection
>
> ("Connection: close" --> "Connection: Keep-Alive") seem to be incorrect without implementation of support for persistent connections.
>
> Thanks,
> Alexander
>
>
>> Java 5 Enhancement: java.net.HttpURLConnection should send request head with a connection-field of "Keep-Alive"
>> ---------------------------------------------------------------------------------------------------------------
>>
>> Key: HARMONY-499
>> URL: http://issues.apache.org/jira/browse/HARMONY-499
>> Project: Harmony
>> Type: Improvement
>>
>
>
>> Components: Classlib
>> Reporter: Richard Liang
>> Assignee: Tim Ellison
>> Priority: Minor
>> Attachments: luni.src.net.diff
>>
>> Hello,
>> java.net.HttpURLConnection should send request head with a default connection-field of "Keep-Alive". Currently in its implementation, it sends a connection-field of "close", but does not close its own socket after connection, which may cause low performance and strange behavior on some servers.
>> Best regards,
>> Richard
>>
>
>
--
Richard Liang
China Software Development Lab, IBM
Re: [classlib][luni]Http persistent connection(was Re: [jira] Commented: (HARMONY-499))
Posted by Stepan Mishura <st...@gmail.com>.
On 7/24/06, Paulex Yang wrote:
>
> Seems no others interest in this;), so I'm going to assign harmony-617
> to myself and implement a connection pool if no one objects.
>
> I may need a couple of days to implement and test it, so I plan to add
> the class skeleton to o.a.h.luni.net, and enrich them step by step,
> until at last I'll refactory HttpURLConnection to use it , maybe also
> need to refactor HttpsURLConnection, though I expect little modification
> needed for it. (Or I need to implement them in sandbox at first?)
>
> A question is about RI's specific properties support[1], say
> |sun.net.http.errorstream.enableBuffering,| etc, do we need to support
> them, too?
IANAL, I think it is OK to use the guide for implementing the same set of
system properties that control the connection behavior. But I'm not sure
that it is legal to use implementation specific names for them (like you
have mentioned - sun.net.http.errorstream.enableBuffering). May be it makes
sense to ask for permission like Geir did for exception messages and
toString() formats.
Thanks,
Stepan.
[1] http://java.sun.com/j2se/1.5.0/docs/guide/net/http-keepalive.html
>
> Paulex Yang wrote:
> > Alexander,
> >
> > I modified the subject to make it more obvious:). Sorry at first for
> > responsing so late, I was a little distracted by the NIO work. I agree
> > with you that option 1 and 2 below is feasible, and I have some rough
> > thoughts on the cache mechanism, I'm interested in how others think
> > about them.
> >
> > The connection pool should:
> >
> > a. has different protocals support, with handy and consistent
> > interface to HttpURLConnection and HttpsURLConnection
> > b. proxy issue, SSL connection via proxy is based on plain socket, so
> > it must be handled but should be transparent to users
> > c. the cached sockets' lifecycle
> > (max-number/create/cache/synchronization/validation/idle connection
> > collection/finalization) is managed transparently to users
> > d. performance of the pool (say, over-synchronization, and other issue?)
> >
> > Wow...seems pretty much work! So, ideas and comments?
> >
> > Alexander Kleymenov wrote:
> >> Paulex,
> >>
> >> On 6/1/06, Paulex Yang <pa...@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
> >> ones.
> >>
> >>> , 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.connect(address);
> >> 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
> >> sockets.
> >>
> >> 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
> >> HttpUC).
> >> Persistent connection mechanism should be implemented in HttpUC in
> >> such a way that it could store SSL and plain sockets and distinguish
> >> them.
> >>
> >>>
> >>> 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,
> >> Alexander
> >>
>
>
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
------------------------------------------------------
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
Re: [classlib][luni]Http persistent connection(was Re: [jira] Commented:
(HARMONY-499))
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Paulex Yang wrote:
> Seems no others interest in this;), so I'm going to assign harmony-617
> to myself and implement a connection pool if no one objects.
>
> I may need a couple of days to implement and test it, so I plan to add
> the class skeleton to o.a.h.luni.net, and enrich them step by step,
> until at last I'll refactory HttpURLConnection to use it , maybe also
> need to refactor HttpsURLConnection, though I expect little modification
> needed for it. (Or I need to implement them in sandbox at first?)
>
> A question is about RI's specific properties support[1], say
> |sun.net.http.errorstream.enableBuffering,| etc, do we need to support
> them, too?
>
> [1] http://java.sun.com/j2se/1.5.0/docs/guide/net/http-keepalive.html
Yes, it seems that would be best, to ensure that existing programs work
as close to expected as we can.
geir
---------------------------------------------------------------------
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
Re: [classlib][luni]Http persistent connection(was Re: [jira] Commented:
(HARMONY-499))
Posted by Paulex Yang <pa...@gmail.com>.
Seems no others interest in this;), so I'm going to assign harmony-617
to myself and implement a connection pool if no one objects.
I may need a couple of days to implement and test it, so I plan to add
the class skeleton to o.a.h.luni.net, and enrich them step by step,
until at last I'll refactory HttpURLConnection to use it , maybe also
need to refactor HttpsURLConnection, though I expect little modification
needed for it. (Or I need to implement them in sandbox at first?)
A question is about RI's specific properties support[1], say
|sun.net.http.errorstream.enableBuffering,| etc, do we need to support
them, too?
[1] http://java.sun.com/j2se/1.5.0/docs/guide/net/http-keepalive.html
Paulex Yang wrote:
> Alexander,
>
> I modified the subject to make it more obvious:). Sorry at first for
> responsing so late, I was a little distracted by the NIO work. I agree
> with you that option 1 and 2 below is feasible, and I have some rough
> thoughts on the cache mechanism, I'm interested in how others think
> about them.
>
> The connection pool should:
>
> a. has different protocals support, with handy and consistent
> interface to HttpURLConnection and HttpsURLConnection
> b. proxy issue, SSL connection via proxy is based on plain socket, so
> it must be handled but should be transparent to users
> c. the cached sockets' lifecycle
> (max-number/create/cache/synchronization/validation/idle connection
> collection/finalization) is managed transparently to users
> d. performance of the pool (say, over-synchronization, and other issue?)
>
> Wow...seems pretty much work! So, ideas and comments?
>
> Alexander Kleymenov wrote:
>> Paulex,
>>
>> On 6/1/06, Paulex Yang <pa...@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
>> ones.
>>
>>> , 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.connect(address);
>> 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
>> sockets.
>>
>> 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
>> HttpUC).
>> Persistent connection mechanism should be implemented in HttpUC in
>> such a way that it could store SSL and plain sockets and distinguish
>> them.
>>
>>>
>>> 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,
>> Alexander
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>
>
--
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
[classlib][luni]Http persistent connection(was Re: [jira] Commented:
(HARMONY-499))
Posted by Paulex Yang <pa...@gmail.com>.
Alexander,
I modified the subject to make it more obvious:). Sorry at first for
responsing so late, I was a little distracted by the NIO work. I agree
with you that option 1 and 2 below is feasible, and I have some rough
thoughts on the cache mechanism, I'm interested in how others think
about them.
The connection pool should:
a. has different protocals support, with handy and consistent interface
to HttpURLConnection and HttpsURLConnection
b. proxy issue, SSL connection via proxy is based on plain socket, so it
must be handled but should be transparent to users
c. the cached sockets' lifecycle
(max-number/create/cache/synchronization/validation/idle connection
collection/finalization) is managed transparently to users
d. performance of the pool (say, over-synchronization, and other issue?)
Wow...seems pretty much work! So, ideas and comments?
Alexander Kleymenov wrote:
> Paulex,
>
> On 6/1/06, Paulex Yang <pa...@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
> ones.
>
>> , 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.connect(address);
> 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
> sockets.
>
> 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
> HttpUC).
> Persistent connection mechanism should be implemented in HttpUC in
> such a way that it could store SSL and plain sockets and distinguish
> them.
>
>>
>> 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,
> Alexander
>
> ---------------------------------------------------------------------
> 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
>
>
--
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
Re: [jira] Commented: (HARMONY-499) Java 5 Enhancement: java.net.HttpURLConnection should send request head with a connection-field of "Keep-Alive"
Posted by Alexander Kleymenov <kl...@gmail.com>.
Paulex,
On 6/1/06, Paulex Yang <pa...@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
ones.
>, 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.connect(address);
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
sockets.
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
HttpUC).
Persistent connection mechanism should be implemented in HttpUC in
such a way that it could store SSL and plain sockets and distinguish
them.
>
> 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,
Alexander
---------------------------------------------------------------------
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
Re: [jira] Commented: (HARMONY-499) Java 5 Enhancement: java.net.HttpURLConnection
should send request head with a connection-field of "Keep-Alive"
Posted by Paulex Yang <pa...@gmail.com>.
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
Re: [jira] Commented: (HARMONY-499) Java 5 Enhancement: java.net.HttpURLConnection should send request head with a connection-field of "Keep-Alive"
Posted by Alexander Kleymenov <kl...@gmail.com>.
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. 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.
Thanks,
Alexander
Re: [jira] Commented: (HARMONY-499) Java 5 Enhancement: java.net.HttpURLConnection
should send request head with a connection-field of "Keep-Alive"
Posted by Paulex Yang <pa...@gmail.com>.
Alexander Kleymenov (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/HARMONY-499?page=comments#action_12414202 ]
>
> Alexander Kleymenov commented on HARMONY-499:
> ---------------------------------------------
>
> Hello,
>
> I am working on HttpsURLConnection and noticed this JIRA report.
>
> I went through the Java 5 Enhancements for Networking and could not found any statements for HttpURLConnection.
>
> Then I examined the HTTP protocol specification
> (RFC 2616 can be found at http://www.ietf.org/rfc/rfc2616.txt).
> It says:
> "HTTP/1.1 applications that do not support persistent connections MUST
> include the "close" connection option in every message."
>
> The source file of HttpURLConnection implementation does not seem to support persistent connections.
>
> So recent changes made to the class
>
> org.apache.harmony.luni.internal.net.www.protocol.http.HttpURLConnection
>
> ("Connection: close" --> "Connection: Keep-Alive") seem to be incorrect without implementation of support for persistent connections.
>
Alexander,
Let Richard speak for himself, but I agree with you that we should
provide the support for persistent connections, as the spec hints:
" Each HttpURLConnection instance is used to make a single request but
the underlying network connection to the HTTP server may be
transparently shared by other instances. Calling the close() methods on
the InputStream or OutputStream of an HttpURLConnection after a request
may free network resources associated with this instance but has no
effect on any shared persistent connection. Calling the disconnect()
method may close the underlying socket if a persistent connection is
otherwise idle at that time."
My idea is some internal socket pool should be maintained, and this
mechanism should can be shared between HttpURLConnection and
HttpsURLConnection, do you have any suggestions on this issue?
> Thanks,
> Alexander
>
>
>> Java 5 Enhancement: java.net.HttpURLConnection should send request head with a connection-field of "Keep-Alive"
>> ---------------------------------------------------------------------------------------------------------------
>>
>> Key: HARMONY-499
>> URL: http://issues.apache.org/jira/browse/HARMONY-499
>> Project: Harmony
>> Type: Improvement
>>
>
>
>> Components: Classlib
>> Reporter: Richard Liang
>> Assignee: Tim Ellison
>> Priority: Minor
>> Attachments: luni.src.net.diff
>>
>> Hello,
>> java.net.HttpURLConnection should send request head with a default connection-field of "Keep-Alive". Currently in its implementation, it sends a connection-field of "close", but does not close its own socket after connection, which may cause low performance and strange behavior on some servers.
>> Best regards,
>> Richard
>>
>
>
--
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
[jira] Commented: (HARMONY-499) Java 5 Enhancement:
java.net.HttpURLConnection should send request head with a connection-field
of "Keep-Alive"
Posted by "Alexander Kleymenov (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-499?page=comments#action_12414202 ]
Alexander Kleymenov commented on HARMONY-499:
---------------------------------------------
Hello,
I am working on HttpsURLConnection and noticed this JIRA report.
I went through the Java 5 Enhancements for Networking and could not found any statements for HttpURLConnection.
Then I examined the HTTP protocol specification
(RFC 2616 can be found at http://www.ietf.org/rfc/rfc2616.txt).
It says:
"HTTP/1.1 applications that do not support persistent connections MUST
include the "close" connection option in every message."
The source file of HttpURLConnection implementation does not seem to support persistent connections.
So recent changes made to the class
org.apache.harmony.luni.internal.net.www.protocol.http.HttpURLConnection
("Connection: close" --> "Connection: Keep-Alive") seem to be incorrect without implementation of support for persistent connections.
Thanks,
Alexander
> Java 5 Enhancement: java.net.HttpURLConnection should send request head with a connection-field of "Keep-Alive"
> ---------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-499
> URL: http://issues.apache.org/jira/browse/HARMONY-499
> Project: Harmony
> Type: Improvement
> Components: Classlib
> Reporter: Richard Liang
> Assignee: Tim Ellison
> Priority: Minor
> Attachments: luni.src.net.diff
>
> Hello,
> java.net.HttpURLConnection should send request head with a default connection-field of "Keep-Alive". Currently in its implementation, it sends a connection-field of "close", but does not close its own socket after connection, which may cause low performance and strange behavior on some servers.
> Best regards,
> Richard
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-499) Java 5 Enhancement:
java.net.HttpURLConnection should send request head with a connection-field
of "Keep-Alive"
Posted by "Richard Liang (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-499?page=comments#action_12413678 ]
Richard Liang commented on HARMONY-499:
---------------------------------------
Thanks Tim,
It looks fine. Please close this issue.
> Java 5 Enhancement: java.net.HttpURLConnection should send request head with a connection-field of "Keep-Alive"
> ---------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-499
> URL: http://issues.apache.org/jira/browse/HARMONY-499
> Project: Harmony
> Type: Improvement
> Components: Classlib
> Reporter: Richard Liang
> Assignee: Tim Ellison
> Priority: Minor
> Attachments: luni.src.net.diff
>
> Hello,
> java.net.HttpURLConnection should send request head with a default connection-field of "Keep-Alive". Currently in its implementation, it sends a connection-field of "close", but does not close its own socket after connection, which may cause low performance and strange behavior on some servers.
> Best regards,
> Richard
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (HARMONY-499) Java 5 Enhancement:
java.net.HttpURLConnection should send request head with a connection-field
of "Keep-Alive"
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-499?page=all ]
Tim Ellison resolved HARMONY-499:
---------------------------------
Resolution: Fixed
Thanks Richard,
Patch applied to modules\luni\src\main\java\org\apache\harmony\luni\internal\net\www\protocol\http\HttpURLConnection.java at repo revision r409653 .
Please check that the patch was applied as you expected.
> Java 5 Enhancement: java.net.HttpURLConnection should send request head with a connection-field of "Keep-Alive"
> ---------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-499
> URL: http://issues.apache.org/jira/browse/HARMONY-499
> Project: Harmony
> Type: Improvement
> Components: Classlib
> Reporter: Richard Liang
> Assignee: Tim Ellison
> Priority: Minor
> Attachments: luni.src.net.diff
>
> Hello,
> java.net.HttpURLConnection should send request head with a default connection-field of "Keep-Alive". Currently in its implementation, it sends a connection-field of "close", but does not close its own socket after connection, which may cause low performance and strange behavior on some servers.
> Best regards,
> Richard
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (HARMONY-499) Java 5 Enhancement:
java.net.HttpURLConnection should send request head with a connection-field
of "Keep-Alive"
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-499?page=all ]
Tim Ellison reassigned HARMONY-499:
-----------------------------------
Assign To: Tim Ellison
> Java 5 Enhancement: java.net.HttpURLConnection should send request head with a connection-field of "Keep-Alive"
> ---------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-499
> URL: http://issues.apache.org/jira/browse/HARMONY-499
> Project: Harmony
> Type: Improvement
> Components: Classlib
> Reporter: Richard Liang
> Assignee: Tim Ellison
> Priority: Minor
> Attachments: luni.src.net.diff
>
> Hello,
> java.net.HttpURLConnection should send request head with a default connection-field of "Keep-Alive". Currently in its implementation, it sends a connection-field of "close", but does not close its own socket after connection, which may cause low performance and strange behavior on some servers.
> Best regards,
> Richard
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira