Soitenny! (note that I had to trim the thread due to list size limits) First, we'll cover the bare basics of WinInet and WinHTTP. You'll have to put on your developer hat for this one, though cuz I'm about to "background" you a bunch... First a couple of links from MSDN: WinInet: http://msdn.microsoft.com/library/en-us/wininet/wininet/portal.asp WinHTTP: http://msdn.microsoft.com/library/en-us/winhttp/http/winhttp_start_page. asp The most generic term that can be applied to either WinInet or WinHTTP is "Internet library", since they both provide similar APIs for HTTP and FTP-over-HTTP traffic. Unlike WinInet, WinHTTP has no support for direct FTP communications; you *must* use a CERN proxy to access FTP sites with WinHTTP; but enough of that... You'll also hear wild rumors of other things such as XMLHTTP and ServerXMLHTTP, but these are just wrappers around WinInet and WinHTTP, respectively. By the same token, neither of them should be confused with Winsock, which is another layer them and the actual TCP/IP stack. Basically, they all look sorta like this in the "grand scheme of things" (look out, Alexandre; more ASCII art for ya): YourApplication.exe | | WinInet WinHTTP |___________| | Winsock <----> Firewall Client | TCP/IP | Yadda WinInet - proxy configuration registry Policy: HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ProxySettingsPerUser. Default user: HKU\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Internet Settings Interactive user: HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings System: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings Which one of the above locations is used depends on whether or not an actual user account is in use (logged in or impersonated) and the setting of the ProxySettingsPerUser value. If this is set to 0, then only the System default proxy settings will be used by WinInet-based applications. Note that the proxy configuration used by IE is the default proxy configuration used by any other application that makes use of WinInet *unless* they explicitly change them as described in http://msdn.microsoft.com/library/en-us/wininet/wininet/setting_and_retr ieving_internet_options.asp. Unfortunately, if they only change them for the current session, there's no way you can determine this except via netcap analysis. WinHTTP - proxy config registry HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp As you can see (you can, can't you?), WinHTTP proxy configuration is simpler than WinInet because it uses only one location. The preferred method of configuring WinHTTP proxy is via the use of ProxyCfg.exe, a tool written specifically to handle this task. This KB addresses an updated version of the tool: http://support.microsoft.com/kb/830605/en-us. WinHTTP does (almost) understand how to use the wpad script, but with limitations as outlined here: http://msdn.microsoft.com/library/en-us/winhttp/http/autoproxy_issues_in _winhttp.asp. Using ProxyCfg, you have two options; direct or specific proxy. Note that you don't get to specify "auto-" or "config URL". What they don't tell you is that if there are no values stored here, WinHTTP will defer to the WinInet settings, which is why OL2K3 usually seems to "obey" IE configuration. If WinInet is configured for wpad, then WinHTTP will use it, too. WPAD While WinHTTP and WinInet both understand how to retrieve and consume the wpad script, the calling application can also instruct both to use either static proxy or wpad (called "autoproxy" by WinHTTP). To answer your "SBS wpad" question, there is nothing special about the wpad package I built for SBS; the package merely takes advantage of the fact that this script is available via the Web Proxy listener as well as the auto-configuration listener. IOW, nothing will change for this package when SP2 hits the streets. GPO ..of course, GPO WinInet (IE) settings affect how and WinHTTP applications behave as well... WTF? The biggest question in anyone's mind is less likely to be "what does each do?", but more "how do I know when app <blah> is using one or the other?", or "how do I control the behavior of app <blah>?", or even "will you just get on with it?!?" This is a toughie. Determining library usage for app <blah>: The simplest thing I can recommend is that you learn to use winhttptracecfg. This tool enables you to configure WinHTTP tracing so that you can not only determine what applications or services are using WinHTTP, you can also see what they're doing "on the wire". Instructions for use of this tool are found here: http://msdn.microsoft.com/library/en-us/winhttp/http/winhttptracecfg_exe __a_trace_configuration_tool.asp. My fav cmd-line is: Winhttptracecfg -e 1 -l c:\<TestName>. This enables WinHTTP tracing and configures it to write to a file on C:\ with a filename starting with <TestName>, so that I have an idea what I was about when this file was written. If this file gets created when I run my app, then I know it's using WinHTTP; otherwise, it's using WinInet or custom code (ew). The only way you can see if an app is using WinInet is to either ask the developers or sun it under a debugger and watch the system calls. By default, WinHTTP tracing adds to the filename so that you know what process was being logged and the date/time of the start of the logging, as: "WinMedia-wmplayer.exe-1236.10.27.05.660-01.29.2006.LOG". Since WinHTTP tracing creates a file "per-process", it's sometimes fun to enable WinHTTP tracing to see what things are happening on your system that you don't even know about. Just remember to disable it or it'll run forever. How do I control how app <blah> behaves? This is the real problem isn't it? How can I make app (1) act as a web proxy client, but app (2) act as a SecureNET client, and app (3) act as a Firewall Client, all the while allowing app (4) to take nudie pictures of me while my webcam is broken (did I really say that out loud)?. Unfortunately, there isn't a "one size fits all" answer because: - Not all applications are proxy-aware - Not all applications allow you any form of control over their behavior - Not all applications allow you the same level of control - Not all applications behave the same when configured as <blah> - Not all application developers have a freakin' clue how to write code that behaves properly In general follow these guidelines: - use WinInet settings first - both WinInet and WinHTTP use these by default - use wpad whenever possible; if the applications can properly consume it, you get one-stop shopping for your proxy config - use system-level settings and disable per-user settings. This can help keep the users from buggering themselves (unless app (4) is in use). - use proxycfg only when you've positively determined that the settings you created for app (1) don't' adversely affect apps (2) through (4) (especially (4)). Next entry in the thread == Java app. -------------------------------------------- Jim Harrison MCP(NT4, W2K), A+, Network+, PCG http://isaserver.org/Jim_Harrison/ http://isatools.org Read the help / books / articles! -------------------------------------------- -----Original Message----- From: Amy Babinchak [mailto:amy@xxxxxxxxxxxxxxxxxxxxxxxxxx] Sent: Sunday, January 29, 2006 1:54 PM To: [ISAserver.org Discussion List] Subject: [isalist] RE: Web Client Requests http://www.ISAserver.org Jim, I'm not familiar with the difference between winhttp and wininet. Can you explain? Since Outlook uses the settings from the security tab in IE, I had assumed that IE and Outlook did everything the same. This was a grand assumption but it made sense at the time. So back to the java apps that caused me to ask the original question...the answer of add 127.0.0.1 into the local host list in IE might or might not work depending on the java app? You also said that the wpad script with SP2 will have some code to work around the issue of IE thinking that anything with a dot is an external address, will this update be included in the "special" wpad for SBS? I'm thinking that now that I have the IIS set up with the WPAD script there that I could just put the new WPAD download in its place. Will this work? Thanks for taking the time to explain stuff like this to network packet challenged people like me. As a general admin, I don't have to get into this stuff deeply very often. Amy All mail to and from this domain is GFI-scanned.