Hi
Is this the right place to discuss/post patches for Java 1.7? If not,
what is? Sun's websites are so confusing...
Has there been any work on the bug I referred to in the subject? If
not, read on.
On most operating systems (Windows being the exception as usual),
binding to a non-0.0.0.0 IP add
e to use this
solution (with some way to change socket identity) in a patch that
adds a java.net.HttpSocketImpl class similar to the
java.net.SocksSocketImpl class that's already used to tunnel through
SOCKS proxies? If not, in what other way should such a patch be done?
Thank you
Damjan Jova
ge of the authentication schemes it already supports. Not a
> big deal, just needs to be done.
Then I'll try to get it done.
> -Chris.
Thank you
Damjan Jovanovic
> On 21/02/2010 13:09, Damjan Jovanovic wrote:
>>
>> Hi
>>
>>> From http://bugs.sun.com/view_bu
many sockets
as it takes and somehow adopt the final socket into
HttpConnectSocketImpl's own.
Any suggestions?
> -Chris.
Damjan
> On 21/02/2010 13:09, Damjan Jovanovic wrote:
>>
>> Hi
>>
>>> From http://bugs.sun.com/view_bug.do?bug_id=6370908
>>
>>
nnection through a different socket to check
the SOCKS version?
Most applications avoid this problem by treating SOCKSv4 and SOCKSv5
proxies as completely different proxy types.
Thank you
Damjan Jovanovic
this RFE never made
> it back yet and has been sitting for a few years now.
> -Chris.
>
> On 24/02/2010 17:28, Damjan Jovanovic wrote:
>>
>> On Mon, Feb 22, 2010 at 5:02 PM, Christopher Hegarty - Sun
>> Microsystems Ireland wrote:
>>>
>>> Hi Damja
sing
> HttpURLConnection directly and having its socket exposed. Though, I'm still
> not convinced of this solution either.
>
> -Chris
>
> Damjan Jovanovic wrote:
>>
>> Hi Chris
>>
>> I think that without authentication, you'll just get another RFE
Can I also suggest that Proxy.Type.SOCKS gets deprecated and
Proxy.Type.SOCKS4 and Proxy.Type.SOCKS5 get introduced instead?
Just about every application treats SOCKS 4 and 5 as different proxy
types, only Java tries to lump them together.
On Wed, Jan 12, 2011 at 5:04 PM, Chris Hegarty wrote:
>
th 1024 bits (a common
value), you only have to create >= 1021 file descriptors (and of course
stdin/stdout/stderr) to exceed this limit, and end up with a file
descriptor for which FD_SET breaks. This will be the case even if that file
descriptor is the only file descriptor you are trying to add to the bitset.
Please reconsider.
Regards
Damjan Jovanovic
Guys, there was a patch for this feature (use of HTTP proxies with
CONNECT request in java.net.Socket) floating around in February/March
2010, the latest version of which is at
http://mail.openjdk.java.net/pipermail/net-dev/2010-March/001642.html
I helped write it so let me know if you need any he
> this patch.
>
> Thank you,
> -- Vasiliy
>
>
> On 25.10.2012 18:29, Damjan Jovanovic wrote:
>>
>> Guys, there was a patch for this feature (use of HTTP proxies with
>> CONNECT request in java.net.Socket) floating around in February/March
>> 2010, the latest
11 matches
Mail list logo