Thanks Joseph—I really appreciate the explanation and help. I’m still learning a lot about this whole setup.
So, we’ve finally figured out that the Java applet isn’t reading our .pac file at all, and it only took that long because it would work on some computers but not others. Turned out these machines (where it worked) actually had a rule to allow direct access to Akamai for another application, so they were just going direct and working. It is an SSL site that the applet (jpnl file) loads from, so it fails the certificate validation when it tries to go direct and hangs first, then stops the user with a prompt each time they need to print a receipt. Based on this, I’m wondering, are you using JUSTA a proxy.pac file, or is it actually WPAD configuration pointing to a wpad.dat that locates the proxy.pac? In IE for example, we are defining the URL directly to the proxy.pac file (second option), and not using any DNS publishing (Our network admin is heading up this project). So, if you are actually using a proxy.pac with no WPAD, would it be possible to send me (offlist is fine) some of the formats of the functions you have defined? We’re thinking it’s possible that we’ve defined functions that can’t be read, so Java throws the file away like it’s badly formatted. I’ve already gone through and removed all tab characters based on a suggestion I read, but that hasn’t helped. I’ve also read some mentions of removing spaces, but I’m not sure where they mean. I could provide some of our functions if that would help? In the meantime or otherwise, I’ve rolled back the settings to those affected users and will probably have to figure out how to push a manual proxy setting to Java. -Bonnie From: [email protected] [mailto:[email protected]] On Behalf Of Joseph L. Casale Sent: Friday, March 27, 2015 10:36 AM To: [email protected] Subject: [NTSysADM] Re: Java and proxy.pac No, the PAC file points to http://proxy.company.com.<http://proxy.company.com> I do not publish the name of the proxy (app21xyz.company.com etc etc) in the pac file, not worth the maintenance. I had originally set up a generic record "proxy.company.com" as a CNAME and this broke Java when used with SSL sites. So, when a user browsed http://www.some-sight.com any java applets worked. When a user browsed https://www.some-sight.com any applets would go direct. So, manually setting the network settings of the Java applet to force a proxy always fixed it until I noticed the PAC was using the CNAME. I removed the record and replaced it with the same value but as an A record *and* cleared the manual network configuration and Java applets no longer tried to go direct. jlc ________________________________ From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> on behalf of Miller Bonnie L. <[email protected]<mailto:[email protected]>> Sent: Friday, March 27, 2015 10:41 AM To: [email protected]<mailto:[email protected]> Subject: [NTSysADM] RE: Java and proxy.pac No SSL, our net admin can’t make it work that way. Just http://server.name.edu/pacfilename.pac , but there is a cname involved. Are you saying the URL needs the actual server name, even though the record is pointing to the same IP? Yes, it’s an SSL site that is having problems, so might be related. I just found oracle docs : http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/networking/proxie_config.html And if I’m reading right, we might have to also configure the pac file here? We’re putting together a test account right now to play with settings & a copy of the .pac file. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Joseph L. Casale Sent: Friday, March 27, 2015 9:27 AM To: [email protected]<mailto:[email protected]> Subject: [NTSysADM] Re: Java and proxy.pac So, The url is ssl enabled? I found in my env that I had to manually set the proxy settings for Java explicitly until I noticed that the pac file pointed to a dns entry for the proxy server pointed to a CNAME, changed that to the technically correct A record and all the machines that required manual Java network overrides started working with the configuration cleared out. Without the manual Java network configuration, ssl enabled sties bypassed the proxy and attempted to route direct which of course was not available. jlc ________________________________ From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> on behalf of Miller Bonnie L. <[email protected]<mailto:[email protected]>> Sent: Friday, March 27, 2015 10:16 AM To: [email protected]<mailto:[email protected]> Subject: [NTSysADM] Java and proxy.pac After many years, we are FINALLY rolling out a proxy.pac file for our browser settings—been testing with smaller groups of users, and has been fine. So today, we pointed a larger number of users to the file, and now have some calls about a specialized Java applet that is having issues. It’s something that is part of our Student Information system that prints receipts for various items, so used by our Attendance offices and bookkeepers. After some searching, I think it may be that the Java applet is not reading the .pac file, but there seems to be some people who say you can make it work by doing x,y,z (not much detail) and others who say it simply can’t read a .pac file at all. We’ve only tested IE, as apparently this app has never worked right in Chrome (which we also have). So, does anyone have their Java applets successfully using a pac file for proxy autoconfig, and if so, what is the trick? Or, is it a fact that it can’t be done, and if so, what do you do instead? Ours is set up using an http url. Any assistance appreciated—please let me know if more detail is required on anything specific, as this is new territory. TIA, Bonnie
