Thanks Ben--Once our Server applications analyst is back from vacation (he has the rights to receipt printing in our SIS) we should be able to try out this methodology.
I did see something about the space chars and tried going through the file to make sure there weren't any tabs, etc, but that might not be enough, especially if I can't see it. Been using Notepad++ set for .js to edit - if we should use something else, I certainly can give it a go. On the MIME types, is there something that needs to be added/defined for the .pac file type? This web server actually was just migrated from 2003 R2 to 2008 R2, so is pretty "new". I don't think we've had to add any types just yet. -Bonnie -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Ben Scott Sent: Tuesday, March 31, 2015 10:32 AM To: [email protected] Subject: Re: [NTSysADM] RE: Java and proxy.pac On Mon, Mar 30, 2015 at 8:02 AM, Miller Bonnie L. <[email protected]> wrote: > Thanks Ben--yes, the Java app does NOT work if we manually define the > path to the proxy.pac file, which is why I was asking if anyone has it > working this way exacly (with no wpad). That does seem to suggest it's something about your proxy.pac file in particular that Java does not like. That should be fairly easy to test, though. Put a different PAC file on a web server somewhere, and see if Java will accept that one. For example, put the following in a file called "dumb.pac", and put that on the web server. Then point Java to dumb.pac instead of the regular one, using the manually-defined PAC URL option in Java. function FindProxyForURL(url, host) { return "PROXY your.proxy.server.example.com:8080"; } Obviously, change the proxy server name and port number to match your environment. This is the simplest PAC file possible that actually uses a proxy. If Java does not work for you with this, it's prolly not the PAC stuff itself, but something like a bad end-of-line character or a misconfigured web server or something. Incorrect MIME Content-Type definitions on the web server often result in screwy behavior, for example. On the other hand, if Java works with the above, then it's something in your specific PAC file that's causing the problem. Perhaps a feature of JavaScript is being used which Java's interpreter does not understand. > I'm not sure the exact reason, but I've been told we're not going to > use wpad. Maybe this is wrong, but I was told it has something to do > with the setting we are using to split the proxy for the youtube > settings. The more I've read though, it looks like wpad points to a .pac > formatted file, so why would it not work (at least in IE/Chrome) if the .pac > file already works otherwise? Yah, that doesn't make any sense to me. DNS-based WPAD is just a standard name and URL path to look for a PAC file. Even if you were doing something server-side that needed the URL to end in "proxy.pac", you would just make "/wpad.dat" a redirect (I'd recommend that anyway, for clarity). -- Ben
