Bind Local Port For HttpsUrlConnection

We have a clustered Server with a virtual IP address and each machine has, of course, a physical ip address. There is also a proxy/firewall that only allows the virtual ip address to make connections. When using HttpsUrlConnection there is no way to bind to the virtual IP address, and so we are not allowed onto the proxy. My question is, is it possible to request a change to allow this behaviour? Or will I have to create an enitre SSL implementation on my own, in order to be able to do this? Is this a feature that is not allowed due to the U.S. export restirctions? Or is this just something that was not considered?

[629 byte] By [masijadea] at [2007-10-2 22:07:16]
# 1
You won't get a code change out of Sun any time in the next couple of years. You'd be better off getting the firewall reconfigured.
ejpa at 2007-7-14 1:23:59 > top of Java-index,Security,Java Secure Socket Extension (JSSE)...
# 2

I don't understand why, either. This is something that is extremely easy

to change, if you have access to the original source. You simply need

to call the createSocket differently. But, all the classes involved, are

classes that are restricted due to export restrictions, which makes

implementing it yourself extremely involved. For Sun, it should be a

matter of minutes (or maybe upto two hours if things go badly) to

change this.

masijadea at 2007-7-14 1:23:59 > top of Java-index,Security,Java Secure Socket Extension (JSSE)...
# 3

That's not the point. You or I could change it in two minutes. Sun will take years. First they will ignore the request as long as possible. Then they will argue that you don't need it. Then they will hit you for a support contract. Then they discuss it around the JCP and the other Java implementor licencees. Then they put it into a schedule. At this point we are probably already several months down the track. Then the schedule for implementation comes up, which could take any amount of time. Then they spend the two minutes. Then they spend several weeks devising operational and backward compatibility tests. Then they establish that the change works in all conceivable circumstances. Then they document it. Then they put it into the next release, which is presently an 18 month cycle. Then you get your fix.

Get the picture? and I've left out a lot of steps.

ejpa at 2007-7-14 1:23:59 > top of Java-index,Security,Java Secure Socket Extension (JSSE)...