Http Client Protocol Issues

If you use any of these solutions, Please let me know so I can track if any of this is useful to you! Thanks! This is an area to share observations I have made working with Http Client Protocols and the associated technologies. I currently work for the Microsoft team that supports the WinInet, WinHTTP and System.Net API's and classes associated with these technologies. This is not a replacement for Microsoft Support, but an area to discuss these technologies. These postings are provided "AS IS" with no warranties, and confer no rights. Use of included code samples are subject to the terms specified at Microsoft - Information on Terms of Use

WinHttp Proxy configuration on Windows 2003 x64

You may get an error similar to this when running your WinHttp application:

Error: The server name or address could not be resolved
Code: 80072EE7
Source:  WinHttp.WinHttpRequest

The familiar ProxyCfg application allows you to set the proxy settings for WinHttp.  However in this case, your  application is not picking up the proxy settings.  You verify this by setting the Proxy settings to the current user by typing "proxycfg -p myproxyhere" at the command line and you see from a Netmon trace that the proxy is not being utilized. 

Further research shows your application is loading the 32 bit version of WinHttp.  In Windows 2003 x64, there is a directory for the 32 versions of the system components.  You need to run this version for your 32 bit application: c:\windows\sysWow64\proxycfg -p myproxyhere.  This fixes the issue.  In general, on this platform when using proxycfg.exe, you should run the version in system32 and the version in sysWow64 to ensure you set the proxy setting for both versions of WinHttp on the system.

Side note on WinHttp COM registration on Windows 2003 x64

One thing interesting in the default installation of the 64 bit OS is that you will notice WinHttp.dll does not live in either the system32 or the sysWow64 directories.  Also, if you look in the registry under HKCR\CLSID you will see no entry for WinHttp.WinHttpRequest.5.1.  So how does a script succeed that calls CreateObject() on your progId?  The magic here is the SideBySide (SxS) registration of WinHttp.  You will notice there are WinHttp Dlls in the C:\WINDOWS\WinSxS\ subdirectories.  You will also see in C:\WINDOWS\WinSxS\Manifests there are manifest files and the file names contain WINHTTP in them.  Without going into a ton of detail, what happens is CLSIDFromProgID will take the name of the object you are creating and based on the Bitness of the application (64 or 32) there are internal system calls to find the latest version of winhttp and use that for the creation of the object.

That is why you cannot find the ProgID in the registry!

Let me know if this blog helped you out by dropping me a comment please!

Published Tuesday, July 21, 2009 1:42 PM by jpsanders
Filed under:

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

No Comments

Leave a Comment

(required) 
(optional)
(required) 

  
Enter Code Here: Required
Submit

© 2009 Microsoft Corporation. All rights reserved. Terms of Use  |  Trademarks  |  Privacy Statement
Microsoft
Page view tracker