Proxy Auto Configuration thru WinHTTP 5.1 not working for me
Alan Yu
http://wp.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html using
my test program listed below based on MSDN sample code.
Here are those not working using the WinHTTP API.
isResolvable always return false
isInNet works if host is hardcoded, not the "host" parameter from
FindProxyForURL
dnsResolve always return false, instead of string
myIpAddress always return false, instead of string
dateRange always return false
timeRange always return false
Seems all those involing DNS do not work.
Do anybody have similar problem? I am testing on both W2K SP3 Professional
and server. Is it something wrong with my code?
(Of course I can ping, resolve hostname without any problem.)
// pac.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <windows.h>
#include <wchar.h>
#include <Winhttp.h>
void wmain(int argc, WCHAR* argv[])
{
if (argc < 3) {
wprintf(L"usage: %s URL_to_test [autodetect | PAC_URL]\n", argv[0]);
wprintf(L"example: %s http://www.google.com/index.html
http://web_server/proxy.pac\n", argv[0]);
return;
}
BOOL bAutoDetect = (wcscmp(argv[2], L"autodetect") == 0);
HINTERNET hHttpSession = NULL;
WINHTTP_AUTOPROXY_OPTIONS AutoProxyOptions;
WINHTTP_PROXY_INFO ProxyInfo;
DWORD cbProxyInfoSize = sizeof(ProxyInfo);
ZeroMemory( &AutoProxyOptions, sizeof(AutoProxyOptions) );
ZeroMemory( &ProxyInfo, sizeof(ProxyInfo) );
//
// Create the WinHTTP session
//
hHttpSession = WinHttpOpen( L"WinHTTP AutoProxy Sample/1.0",
WINHTTP_ACCESS_TYPE_NO_PROXY,
WINHTTP_NO_PROXY_NAME,
WINHTTP_NO_PROXY_BYPASS,
0 );
// Exit if WinHttpOpen failed
if( !hHttpSession )
goto Exit;
//
// Set up the autoproxy call
//
if (bAutoDetect)
{
// Use auto-detection since we do not know a Proxy Auto-Config URL.
AutoProxyOptions.dwFlags = WINHTTP_AUTOPROXY_AUTO_DETECT;
// use both DHCP and DNS-based auto-detection
AutoProxyOptions.dwAutoDetectFlags = WINHTTP_AUTO_DETECT_TYPE_DHCP |
WINHTTP_AUTO_DETECT_TYPE_DNS_A;
}
else
{
// The proxy auto-config URL is already known, so auto-detection
// is not needed.
AutoProxyOptions.dwFlags = WINHTTP_AUTOPROXY_CONFIG_URL;
// Set the proxy auto-config URL
AutoProxyOptions. lpszAutoConfigUrl = argv[2];
}
// If obtaining the PAC script requires NTLM/Negotiate
// authentication, then automatically supply this client's
// domain credentials
AutoProxyOptions.fAutoLogonIfChallenged = TRUE;
//
// Call WinHttpGetProxyForUrl with our target URL.
if( WinHttpGetProxyForUrl( hHttpSession,
argv[1],
&AutoProxyOptions,
&ProxyInfo))
{
wprintf(L"WinHttpGetProxyForUrl returns TRUE\n");
wprintf(L"WINHTTP_PROXY_INFO.dwAccessType = ");
switch (ProxyInfo.dwAccessType)
{
case WINHTTP_ACCESS_TYPE_DEFAULT_PROXY:
wprintf(L"WINHTTP_ACCESS_TYPE_DEFAULT_PROXY\n");
break;
case WINHTTP_ACCESS_TYPE_NO_PROXY:
wprintf(L"WINHTTP_ACCESS_TYPE_NO_PROXY\n");
break;
case WINHTTP_ACCESS_TYPE_NAMED_PROXY:
wprintf(L"WINHTTP_ACCESS_TYPE_NAMED_PROXY\n");
break;
}
wprintf(L"WINHTTP_PROXY_INFO.lpszProxy = %s\n", ProxyInfo.lpszProxy);
wprintf(L"WINHTTP_PROXY_INFO.lpszProxyBypass = %s\n",
ProxyInfo.lpszProxyBypass);
}
else
{
DWORD dwErr = GetLastError();
wprintf(L"WinHttpGetProxyForUrl returns FALSE with error ");
switch (dwErr)
{
case ERROR_WINHTTP_AUTODETECTION_FAILED:
wprintf(L"ERROR_WINHTTP_AUTODETECTION_FAILED\n");
break;
case ERROR_WINHTTP_BAD_AUTO_PROXY_SCRIPT:
wprintf(L"ERROR_WINHTTP_BAD_AUTO_PROXY_SCRIPT\n");
break;
case ERROR_WINHTTP_INCORRECT_HANDLE_TYPE:
wprintf(L"ERROR_WINHTTP_INCORRECT_HANDLE_TYPE\n");
break;
case ERROR_WINHTTP_INVALID_URL:
wprintf(L"ERROR_WINHTTP_INVALID_URL\n");
break;
case ERROR_WINHTTP_LOGIN_FAILURE:
wprintf(L"ERROR_WINHTTP_LOGIN_FAILURE\n");
break;
case ERROR_WINHTTP_UNABLE_TO_DOWNLOAD_SCRIPT:
wprintf(L"ERROR_WINHTTP_UNABLE_TO_DOWNLOAD_SCRIPT\n");
break;
case ERROR_WINHTTP_UNRECOGNIZED_SCHEME:
wprintf(L"ERROR_WINHTTP_UNRECOGNIZED_SCHEME\n");
break;
}
}
Exit:
//
// Clean up the WINHTTP_PROXY_INFO structure
//
if( ProxyInfo.lpszProxy != NULL )
GlobalFree(ProxyInfo.lpszProxy);
if( ProxyInfo.lpszProxyBypass != NULL )
GlobalFree( ProxyInfo.lpszProxyBypass );
//
// Close the WinHTTP handles
//
if( hHttpSession != NULL )
WinHttpCloseHandle( hHttpSession );
}
Stephen Sulzer [MSFT]
Bad news, unfortunately.
The isResolveable, myIPAddress and dnsResolve proxy script support functions
in WinHTTP are broken. It appears that dnsResolve and isResolveable will
work only if the host string parameter contains an IPv4 literal address;
they will not work for DNS names.
dateRange and timeRange are not implemented by WinHTTP. That is currently
by-design.
I haven't been able to confirm the issue with isInNet yet, but that sounds
like a bug too.
The broken isResolveable, myIPAddress and dnsResolve functionality is a
serious defect. Currently there is no timeframe for when a fix could be
available. I would recommend that you contact Microsoft Product Support
Services, report and escalate the issue, and request a hotfix.
Regards,
Stephen Sulzer
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.
"Alan Yu" <ak...@rogers.com> wrote in message
news:#pkfaL13...@TK2MSFTNGP11.phx.gbl...
Ron DeFulio
I was putting together this message to email to you directly when I
discovered this thread on the newsgroups, so I will post it instead.
I've been attempting to migrate to WinHTTP 5.1 and I've found several
show stoppers on the new version. I don't see a whole lot of
discussion in the newsgroups about this dll so I take it there aren't
many people using the features. Here are the issues I've found:
Basic authentication to a web site via WinHTTP 5.1 Fails to
authenticate. If I change my COM reference (in vb6) to the 5.0
version instead of the 5.1 version, my BASIC authentication works once
again. I can post relevant source code if it would be helpful.
Auto-Proxy detection does not evaluate autoconfing (PAC) scripts
identically to IE 6.0. Some javascript functions (such as isInNet and
dnsResolve) are broken. Specifically, the isInNet() function only
works if you pass it an IP address as the first parameter, even though
it is documented that it's supposed to accept a hostname or an IP.
Also, the dnsResolve() function is supposed to convert a hostname to
an ip address and it incorrectly returns to 'false' for any string
passed to it. As a result of these errors, auto-proxy-detection will
fail on customer networks that utilize these functions as part of
their autoproxy pac file (which works correctly in IE6). It'll
basically be hit-or-miss if trying to utilize auto proxy detection at
a new customer site.
Calling for an End-Of-Life on WinHTTP 5.0 when 5.1 still contains
significant bugs is a premature move. If there is a newer version of
WinHTTP.dll please let me know so I can test these issues with that
version.
My version of winhttp.dll is 5.1.2600.1106, which ships with Windows
XP SP1.
Thanks
Ron DeFulio
PS: Since it appears I am not the only one encountering this problem
with the autoproxy support, I would hope that posting my findings here
will help escalate the problem further.
"Stephen Sulzer [MSFT]" <ssu...@online.microsoft.com> wrote in message news:<uyBHsl53...@TK2MSFTNGP11.phx.gbl>...
Stephen Sulzer [MSFT]
[Please use this newsgroup for WinHTTP discussion; do not send unsolicited
e-mail directly to Microsoft personnel who post on the newsgroup. Thanks.]
Regarding the problem with Basic authentication: please give more details
about the problem and the scenario, including code samples, proxy
configuration, error and HTTP status codes received, whether the request is
via HTTPS/SSL, and a WinHTTP trace log if possible.
With regards to the isInNet(), dnsResolve() and other proxy script support
functions, a fix should be available via Microsoft PSS soon. This issue was
escalated by another customer and a QFE hotfix was developed. Please contact
Microsoft PSS and refer to KB article number Q816941.
Overall, WinHTTP 5.1 is of a much higher quality that version 5.0. WinHTTP
5.1 contains fixes for many problems that exist in 5.0. (The Auto-Proxy
feature is new in 5.1.) The most up-to-date version of WinHTTP will ship in
Windows Server 2003. WinHTTP 5.1 is an OS component, and is updated only via
new Windows operating system releases, Windows service packs and QFE
hotfixes. WinHTTP 5.0 will continue to be supported through October 1st,
2004.
Regards,
Stephen Sulzer
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.
"Ron DeFulio" <d0...@hotmail.com> wrote in message
news:89df091d.03032...@posting.google.com...
Ron DeFulio
Thanks for your quick reply. I've discovered a different thread in
this group that discusses my exact authentication issue.
See Message "Problems using WinHttp with Proxy and Server
Authentication simultaneously"
It appears this is also a known issue so I will try and track down
Q816941.
Thanks again,
Ron DeFulio
"Stephen Sulzer [MSFT]" <ssu...@online.microsoft.com> wrote in message news:<O5MC#R08CH...@TK2MSFTNGP10.phx.gbl>...