Changeset: 48b7295f02f8
Author:chegar
Date: 2013-03-07 10:07 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/48b7295f02f8
6370908: Add support for HTTP_CONNECT proxy in Socket class
Reviewed-by: chegar
Contributed-by: Damjan Jovanovic , Chris Hegarty
+ src/share/classes
On 04/03/2013 12:46, Florian Weimer wrote:
On 03/04/2013 11:07 AM, Chris Hegarty wrote:
Unless I hear otherwise, I'd like to go ahead an commit this patch to
jdk8. It has been sitting around for a while now, see [1], and more
recently [2].
http://cr.openjdk.java.net/~chegar/6370908/webrev.01/we
Unless I hear otherwise, I'd like to go ahead an commit this patch to
jdk8. It has been sitting around for a while now, see [1], and more
recently [2].
http://cr.openjdk.java.net/~chegar/6370908/webrev.01/webrev/
-Chris.
[1] http://mail.openjdk.java.net/pipermail/net-dev/2010-March/001642.htm
Hi Damjan,
I've come full circle on this and created a new webrev based on your
original proposal. Using the current HTTP protocol handler that already
implements the tunneling and authentication. See the updated webrev:
http://cr.openjdk.java.net/~chegar/6370908/webrev.01/
I've used "more
Haven't read the full thread, just 2 cents on this specific paragraph.
On Mar 4, 2010, at 7:29 PM, Damjan Jovanovic wrote:
> Hi Chris
>
> ...
> * pidgin (www.pidgin.im), an instant messaging app, has very good
> proxy support including NTLM authentication for HTTP proxies. It only
> uses a singl
Hi Chris
Proxies are on the application layer, TCP is a transport layer
protocol below. Using the application layer to establish in-band
transport layer connections is dodgy by its very nature. The multiple
sockets to get through an HTTP proxy issue is not unique to Java.
Here's a quick look at ho
Hi Damjan,
After spending more time looking at this, I still haven't found an
elegant solution for supporting authentication.
You've correctly identified an issue with the fact we have no guaranteed
of a persistent connection with the proxy. Changing the socket identity
is not as simple as o
Hi Chris
I think that without authentication, you'll just get another RFE
asking for authentication. Many corporate proxies require
authentication, especially for a liberal request like CONNECT.
java.net.Socket seems to delegate its impl field's methods. If we have
another, internal socket in Htt
Hi Damjan,
Sorry for the delayed response, I'm juggling too many things!
I'm not sure how important Authentication is here. I initially pointed
it out, but hadn't done sufficient scoping so didn't encounter these
issues. Let me take another look at it, but I'm wondering if we should
just proc
On Mon, Feb 22, 2010 at 5:02 PM, Christopher Hegarty - Sun
Microsystems Ireland wrote:
> Hi Damjan,
>
> Actually, I did some work on this back in 2006 (!), but never finished it. I
> brought the changes into a mercurial repository and created a webrev:
>
> http://cr.openjdk.java.net/~chegar/63709
On Mon, Feb 22, 2010 at 5:02 PM, Christopher Hegarty - Sun
Microsystems Ireland wrote:
> Hi Damjan,
Hi Christopher
> Actually, I did some work on this back in 2006 (!), but never finished it. I
> brought the changes into a mercurial repository and created a webrev:
>
> http://cr.openjdk.java.ne
Hi Damjan,
Actually, I did some work on this back in 2006 (!), but never finished
it. I brought the changes into a mercurial repository and created a webrev:
http://cr.openjdk.java.net/~chegar/6370908/webrev.00/webrev/
Basically, this change provides the basic functionality, without any
fr
Hi
>From http://bugs.sun.com/view_bug.do?bug_id=6370908
This RFE is basically about getting a TCP socket to tunnel through an
HTTP proxy using the HTTP CONNECT request.
I've found a hack to get this feature to work, using sun.net.*
packages and lots of reflection. Would it be acceptable to use t
13 matches
Mail list logo
