Java SE (Java Platform, Standard Edition)

OK, so even if I hardcode the proxy then look at the console dump it still wants to proxy=direct.
  Here is the deployment.properties for the hard coded proxy:

#deployment.properties
#Tue Oct 21 16:28:28 BST 2014
deployment.proxy.same=true
deployment.proxy.https.port=8180
deployment.proxy.bypass.local=true
deployment.cache.jarcompression=3
deployment.proxy.https.host=10.1.1.236
deployment.javaws.appicon.index=C\:\\Users\\markwilliams\\AppData\\LocalLow\\Sun\\Java\\Deployment\\cache\\6.0\\appIcon\\appIcon.xml
deployment.proxy.http.port=8180
deployment.proxy.ftp.port=8180
deployment.proxy.http.host=10.1.1.236
deployment.proxy.type=1
deployment.console.startup.mode=SHOW
deployment.proxy.ftp.host=10.1.1.236
deployment.javaws.viewer.bounds=480,314,720,360
deployment.trace=true
deployment.javaws.splash.index=C\:\\Users\\markwilliams\\AppData\\LocalLow\\Sun\\Java\\Deployment\\cache\\6.0\\splash\\splash.xml
deployment.modified.timestamp=1413905308734
deployment.log=true
deployment.version=7.21
deployment.javaws.autodownload=NEVER
install.disable.sponsor.offers=false
#Java Deployment jre's
#Tue Oct 21 16:28:28 BST 2014
deployment.javaws.jre.1.registered=true
deployment.javaws.jre.1.osname=Windows
deployment.javaws.jre.0.registered=true
deployment.javaws.jre.0.platform=1.7
deployment.javaws.jre.1.enabled=true
deployment.javaws.jre.1.location=http\://java.sun.com/products/autodl/j2se
deployment.javaws.jre.0.osname=Windows
deployment.javaws.jre.0.path=C\:\\Program Files (x86)\\Java\\jre7\\bin\\javaw.exe
deployment.javaws.jre.0.product=1.7.0_72
deployment.javaws.jre.1.osarch=amd64
deployment.javaws.jre.1.path=C\:\\Program Files\\Java\\jre7\\bin\\javaw.exe
deployment.javaws.jre.1.platform=1.7
deployment.javaws.jre.0.osarch=x86
deployment.javaws.jre.1.product=1.7.0_04
deployment.javaws.jre.0.location=http\://java.sun.com/products/autodl/j2se
deployment.javaws.jre.0.enabled=true
deployment.javaws.jre.0.args=

the dump trace appears to want to use the proxy but simply wont:

----------------------------------------------------
Dump deployment properties ...
----------------------------------------------------
active.deployment.proxy.bypass.local = true
active.deployment.proxy.ftp.host = 10.1.1.236
active.deployment.proxy.ftp.port = 8180
active.deployment.proxy.http.host = 10.1.1.236
active.deployment.proxy.http.port = 8180
active.deployment.proxy.https.host = 10.1.1.236
active.deployment.proxy.https.port = 8180
active.deployment.proxy.same = true
active.deployment.proxy.type = 1

Frustrating!

We have the same issue.

IE11 proxy set to automatic discovery (WPAD).

Java keeps trying access net with DIRECT directive so applets won't load.

network: Connecting http://www.java.com:443/ with proxy=DIRECT 

Even after set proxy settings directly in Java Control Panel it still using  proxy=DIRECT  (can see it in Java Console).

Folder "%Windir%\Sun\Java\Deployment" is empty.

This  started after upgrade from Java 7 update 67 to 71

Java within firefox works fine  .

I have managed to sort a partial workaround.  If I set the PROXY in IE as a hard coded proxy rather than our PAC file then it works.  If I use either "automatic" to get our WPAD from DNS then it fails with proxy=direct, if I set an autoconfiguration file with our PAC file then again it fails with proxy=direct. If I set a proxy value then it works.

this is not a fix as our PAC and WPAD has various settings inside to farm different hosts to different proxies as appropriate, sending all request to one proxy will not suit our needs.  This is also changed behaviour from 7u67 and 7u60 which worked just fine.

This also means that my proxy settings within the control panel are being totally ignored and the settings within IE are taking precedence - I can prove this by putting one proxy in IE, one in the java control panel and the proxy in IE wins.

We have found the same problems. We cannot do without a Proxy.pac. We hope for a comprehensive solution by Oracle.

Update 23.10.2014: Same Issue with build 7u72 b31

Update 28.11.2014: Repaired in build 7u72 b32. Thanks! What about 8u25?!?

We are also experiencing the same issue.

Java 7u71, 7u72 and 8u25 can not use Internet Explorer proxy-settings if "Use automatic configuration script" is selected (it uses DIRECT).
It works if "Proxy server" is used in IE, but we need to use script/pac.
It also works if we downgrade to Java 7u67, but it will not last for long…

Can we please get at fix ASAP ?

We have found the same problem and narrowed it down to the dnsresolve command.

If I deactivate the command and set the variable to a dummy value, the pac file works as expected. It's just the dnsResolve command.

// var resolved_ip = dnsResolve(host);

var resolved_ip = "1.1.1.1";

We tried deactivating ipv6 at the apapter settings of win7 and setting -Djava.net.preferIPv4Stack=true in the Runtime Parameters in the Java Control Panel () with no success.

Does anyone know how to debug the pac-file execution in Java?

We are also having this exact same problem.

I confirm that problem concerns dnsResolve function.

I found a bug report, which may be related to this:

https://bugs.openjdk.java.net/browse/JDK-8061648

Your dnsResolve request worked for me.  I have a feeling dnsResolve is causing the PAC to break out, I had put a return proxy as a test but crucially this was placed AFTER my dnsResolve (I was using an ALERT to show me what was being requested etc!)

We only have a single domain so the removal of dnsResolve in favour of dnsDomainIS is acceptable.  Marked your answer as correct as it resolved the issue.

EDIT:     Raised bug report with Oracle:     https://bugs.openjdk.java.net/browse/JDK-8062034

OFFTOPIC:     To debug your PAC/WPAD file I did the following and specified the test PAC/WPAD as an automatic configuration script (I would not put this as a default production script!)

var resolved_ip = dnsResolve(host);
var debugPAC ="PAC Debug Information\n";
debugPAC +="-----------------------------------\n";
debugPAC +="Machine IP: " + myIpAddress() + "\n";
debugPAC +="Hostname: " + host + "\n";
if (isResolvable(host)) {resolvableHost = "True"} else {resolvableHost = "False"};
debugPAC +="Host Resolvable: " + resolvableHost + "\n";
debugPAC +="Hostname IP: " + dnsResolve(host) + "\n";
if (isPlainHostName(host)) {plainHost = "True"} else {plainHost = "False"};
debugPAC +="Plain Hostname: " + plainHost + "\n";
debugPAC +="Domain Levels: " + dnsDomainLevels(host) + "\n";
debugPAC +="URL: " + url + "\n";
debugPAC +="Host resolved IP: " + resolved_ip + "\n";
     // Protocol can only be determined by reading the entire URL.
     if (url.substring(0,5)=="http:") {protocol="HTTP";} else
         if (url.substring(0,6)=="https:") {protocol="HTTPS";} else
              if (url.substring(0,4)=="ftp:") {protocol="FTP";}
                 else {protocol="Unknown";}
debugPAC +="Protocol: " + protocol + "\n";

After this put an alert(debugPAC); wherever you want a popup to display the info.  Be warned! this produces quite a few popups.  Plus the dnsResolve breaks in 7u71+ (the whole point of this thread!) so remove that section to test workaround behaviour.

I see that the bug was closed as a duplicate and that the other one is resolved as fixed in 8u40.  Does this mean that we have to wait until the next scheduled CPU for a fix?  I see no other notifications of this issue anywhere other than other bug posts and comments on blogs where additional comments are disabled...Waiting until the middle of January is not acceptable for something that prevents enterprises from updating to a more secured version.  Is anyone privy to additional information?

Our wpad doesn't use dnsResolve but JRE web proxy auto detection was also failing.

In our case isInNet function is also failing.

As workaround we wpdated tests for internal IP addresses to use url.substring as suggested by @2779806.

Oracle needs to fix this and improve their testing

// website is being accessed by IP address instead of FQDN. Treat IANA-reserved private IPv4 network ranges as intranet

//if (isInNet(host, "172.16.0.0", "255.255.0.0")) return "DIRECT";

//if (isInNet(host, "192.168.0.0", "255.255.0.0")) return "DIRECT";

//if (isInNet(host, "10.0.0.0", "255.0.0.0")) return "DIRECT";

//if (isInNet(host, "127.0.0.0", "255.0.0.0")) return "DIRECT";

// test for http or https strings beginning with IANA IP addresses workaround for JRE bug https://bugs.openjdk.java.net/browse/JDK-8062034

if (url.substring(7, 9)=="10." ||

   url.substring(7, 11)=="172.1" ||

   url.substring(7, 13)=="192.168" ||

   url.substring(7, 13)=="155.195" ||

   url.substring(8, 10)=="10." ||

   url.substring(8, 12)=="172.1" ||

   url.substring(8, 14)=="192.168" ) return "DIRECT";

There does appear to be a fix in build 7u72 b32

Java SE 7 Advanced

I've been looking around but can only download the 7u72 b14 version.

How does one obtain different build versions? Sorry if this is a noob question. But any resolution to this that does not include changing our pac file would be greatly appreciated.

Yea, I'm unable to find the 7u72 b32.  I have found the 8u40 b15, which b14 was supposed to fix this issue too, so that may be worth a try.  I haven't tested either of this yet, but even if they work, we aren't going to roll out beta/early release across the enterprise.  When is Oracle going to actually release the fix?  I can't believe this know issue hasn't be resolved in 2+ months.  None of the suggested fixes for proxy work with our firewall, so we are left at the mercy of the next Java release.

Java 8u40 b15: https://jdk8.java.net/download.html

Java 7u80 b03: https://jdk7.java.net/download.html not sure if this is supposed to be a fix either.  A lot of betas and early releases, but NO true updates from Java in over a month. AJP05 said it best "Waiting until the middle of January is not acceptable for something that prevents enterprises from updating to a more secured version"

Just tested with 8u40-b15 AND 7u80-b03.  Both of these versions seem to fix the issues that we were seeing!  We will continue testing on a few lucky computers.  Any status update from Oracle on when either of these will be fully released?

https://jdk7.java.net/download.html

https://jdk8.java.net/download.html

Yeah, we are in the same boat.  The early versions worked, but we are an enterprise, we cannot roll out "beta" versions companywide.  So instead we are sitting on a vulnerable install companywide.  What makes this situation even better is the fact Microsoft implemented a new "feature" to Internet Explorer that automatically disables out of date ActiveX controls!  Unfortunately this new feature slipped through our notice and we received a flood of tickets once 7u67 was deemed out of date.  I love IT.....

We've been running the 8u40 early release (b-15) on a handful of computers for a month now with no issues.  Any word on when the full version will be released?  Would really like to have this resolved so we can revert our other workarounds back to our normal setup.  I don't understand the several month wait on this kind of fix.

*Bump* When is the production release of JRE 8u40 scheduled? I have 7000+ PCs awaiting...

BUMP  Three months and still no fix or update from Oracle, this is more than a LITTLE frustrating.

According to Critical Patch Updates and Security Alerts it is supposed to be released today.

IMO, companies should remember just how non-responsive they have been to releasing a fix for this MAJOR bug and keep it in mind the next time a critical tool needs to be purchased or developed that requires Java.  They've sent a pretty clear message that they would rather leave their customers running vulnerable versions of JRE rather than to release an out-of-band fix that would have kept their customers protected AND their apps working.  It's very frustrating.

Frustrating does't even describe this sufficiently. We are still seeing proxy=direct problems with java apps that use the J Walk Java Client using 1.8.0_40-b25.

Ok, so is there a proper update by now we can safely update to and the DNS lookup via proxy autoconfig/wpad.dat will work?

I am experiencing the same issue.  I have tried 1.8.0_25/40/45/51/60/66 and I get the same outcome with each Java version. 

network: Connecting socket://resncm2.nmcc.sprintspectrum.com:8880 with proxy=DIRECT

This is the error I get whether I use my proxy.pac file or configure the proxy settings manually in IE.   It always tries to go direct.  I hit 'p' on the Java console and see that the proxy settings are whatever I have configured them to be in IE.   I have a wireshark capture and I can see that instead of using the proxy server it is sending packets to resncm2.nmcc.sprintspectrum.com resolved IP address.  It is unreachable on the network and must be accessed via proxy. Java uses the proxy initially and for a while in my application but then it breaks before it finishes loading.  An older version of the application that uses Java 1.6 works. Application is EMC NCM 9.4. 

I am a bit confused how some on this thread say the DNSresolve issue was fixed and they are working now.  It is not working for me.

Carsten, do you still have the problem of "proxy=direct"?   Or did you resolve it? 

Mark  - Did you ever find a resolution as I too am having the same issue.