RE: Web Client Requests

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.



Other related posts: