RE: Web Client Requests
- From: "Thomas W Shinder" <tshinder@xxxxxxxxxxx>
- To: "[ISAserver.org Discussion List]" <isalist@xxxxxxxxxxxxx>
- Date: Sun, 29 Jan 2006 19:09:44 -0600
BRAVO!!!! :))
Thomas W Shinder, M.D.
Site: www.isaserver.org
Blog: http://spaces.msn.com/members/drisa/
Book: http://tinyurl.com/3xqb7
MVP -- ISA Firewalls
**Who is John Galt?**
> -----Original Message-----
> From: Jim Harrison [mailto:Jim@xxxxxxxxxxxx]
> Sent: Sunday, January 29, 2006 5:58 PM
> To: [ISAserver.org Discussion List]
> Subject: [isalist] RE: Web Client Requests
>
> http://www.ISAserver.org
>
> 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_s
> tart_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\Interne
> t 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/settin
> g_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/winhttptr
> acecfg_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!
> --------------------------------------------
>
>
>
Other related posts:
