Windows Core Networking : WinHttp

HTTP Connection Management

AriPernick — Fri, 08 May 2009 19:29:00 GMT

HTTP is a request/response protocol. You request some resource like the HTML of a webpage and the response comes back with the HTML attached. As each request is sent on a connection, the complete response must be read from the connection before the next response can be read. (There is an optimization where you make more requests on a connection before receiving the full response to the previous requests known as pipelining. However it doesn’t change the need to receive all the data from the previous requests first.)

So if an application is asking for another request to a server while the current one is in progress, what’s a HTTP Client API to do? Well, it can either wait till the connection is available or start a new connection. This decision is mostly controlled by a configurable maximum number of simultaneous connections to a server.

With that in mind, how should the following customer question get answered?

My client application’s performance is getting impacted by WinInet opening new SSL connections to my server rather than reusing the existing connection. How do I fix this?

WinHTTP Questions: About Callbacks

wndpteam — Mon, 03 Mar 2008 20:01:00 GMT

Hello All, I am continuing the "WinHTTP Questions" series with some questions on WinHTTP callbacks.

Is it correct that WinHTTP Callbacks will occur *only* during an in-progress WinHTTP operation? Is it possible that an external event (such as the remote server resetting the underlying tcp connection) result in a callback even when there's no outstanding operation?

No. For external callbacks, WinHTTP will indicate informational callbacks only when there is a pending operation. Essentially, there are two types of callbacks in WinHTTP. Completion callbacks and Informational callbacks.

Completion callbacks are invoked as a completion of a pending API call e.g. read complete is invoked when the read API completes. Similarly, handle-closed callback is invoked in response to the close handle API.
Informational callbacks, on the other hand, are invoked to inform the application about important events seen during the processing of a call.

So, when an async API is invoked and it returns TRUE, the application will receive zero or more informational callbacks and then a completion callback.

When an operation like WinHttpReadData fails immediately (i.e., this call returned FALSE), does it guarantee that user will not receive a STATUS_REQUEST_ERROR callback?

Yes.

Does WinHTTP synchronize WinhttpSetStatusCallback with worker threads? Here is our usage scenario: We are implementing a DLL that get dynamically loaded implements an asynchronous Download function with progress notifications and supports a Cancel call. After Cancel or Download completion our DLL should be able to be safely unloaded. Cancel calls WinHttpSetStatusCallback to unregister notifications, closes the request, connection and sessions handles. However we occasionally still get status callbacks after the DLL is unloaded.

No, WinHTTP does not synchronize WinHttpSetStatusCallback with worker threads. For e.g. If a callback originating in another thread is in progress when an application calls WinHttpSetStatusCallback, the application still receives a callback notification even after WinHttpSetStatusCallback successfully sets the callback function to NULL and returns. The thread will continue to process, so one will need to wait until the current call finishes.

Please also refer to the following links for more on callbacks.

Next time we will go a bit deeper into safe request cancellation.

-- Deepak & Ari

WinHTTP Questions - async close on a sync request

wndpteam — Mon, 25 Feb 2008 18:30:00 GMT

Hello, my name is Deepak and I'm a SDET in serviceability. We handle a bunch of questions from developers using WinHTTP, and thought we might share then in a new posting series, "WinHTTP Questions".

Can I cancel a synchronous WinHttpSendRequest call by closing the request handle from a different thread? Or, are there any requirements that I need to use the asynchronous WinHttpSendRequest if I need the ability to cancel it?

The short answer is don't do that.

Let's think about the implications of this proposed code. Thread 1 starts a synchronous request and Thread 2 comes along an issues a close. We can't synchronize between Thread 1 and Thread 2 by definition because Thread 1's call is synchronous, we either can deterministically call the close before the request call starts or after the call is completed. So to close the handle during the call results in a race condition. If thread 2 attempts to close the connection during the call, the handle passed in to WinHttpSendRequest may become invalid before WinHttp has a chance to work with it. While you might get lucky, you might also non-deterministically get a crash or memory corruption.

-- Deepak and Ari

Ask Perf explains how winInet is used

wndpteam — Tue, 21 Aug 2007 20:37:21 GMT

Ask Perf, the blog of the Enterprise Platforms Windows Server Performance Team, is spending some time explaining a bit of how WinInet/WinHTTP and their surrounding components work with each other. Go check it out!

-- Ari

WinHttp Configuration for Windows Vista

wndpteam — Wed, 21 Mar 2007 23:51:00 GMT

In my previous posts, I described the new WinHttp proxy, tracing and client certificate configuration story for Windows Vista Beta2. The syntax of the netsh commands used to configure WinHttp proxy and tracing settings have changed for Vista RTM and this post describes the changes in command syntax since the beta.

WinHttp Netsh Context

From the previous posts you might be aware that in Windows Vista, the WinHttp proxy and tracing configuration tools, proxycfg.exe and winhttptracecfg.exe respectively, have been replaced with netsh commands. All the WinHttp related netsh commands live under the “winhttp” netsh context. To navigate to it, open an administrator command prompt and type “netsh” then “winhttp”:

C:\Windows\system32>netsh netsh>winhttp netsh winhttp>

You can type “?” in this context and display the list of available commands there. You can also type “?” at the end of any command to get a detailed description of the command syntax.

Displaying current settings and restoring the defaults

You can use the “show” netsh commands to display the current settings. “show proxy” will display the current proxy settings, while “show tracing” will display the current tracing settings. You can also use the “reset” netsh command to restore the default settings. “reset proxy” will set the WinHttp proxy settings to DIRECT, while “reset tracing” will disable the tracing.

Setting WinHttp proxy settings

Use the “set proxy” command to configure the proxy settings. You can type the command followed by a question mark to see the syntax:

netsh winhttp>set proxy /? Usage: set proxy [proxy-server=]<server name> [bypass-list=]<hosts list> Parameters: Tag Value proxy-server - proxy server for use for http and/or https protocol bypass-list - a list of sites that should be visited bypassing the proxy (use "<local>" to bypass all short name hosts) Examples: set proxy myproxy set proxy myproxy:80 "<local>bar" set proxy proxy-server="http=myproxy;https=sproxy:88" bypass-list="*.foo.com"

Just follow the examples listed in the samples above to set your proxy settings.

Note that importing proxy settings from IE is now accomplished by the “import” command (importing from IE is the only available option there):

netsh winhttp>import proxy /? Usage: import proxy [source=]ie Parameters: Tag Value source - from where the setting is imported Examples: import proxy source=ie

Setting WinHttp tracing settings

To set the WinHttp tracing settings, use the “set tracing” command from the netsh winhttp context:

netsh winhttp>set tracing /? Usage: set tracing [output=]file|debugger|both [trace-file-prefix=]<string> [level=]default|verbose [format=]ansi|hex [max-trace-file-size=]<number> [state=]enabled|disabled Parameters: Tag Value trace-file-prefix - Prefix for the log file (can include a path) specify "*" to delete an existing prefix output - Where the trace entries are written/displayed to level - How much information to log format - Display format of network traffic (hex or ansi) max-trace-file-size - Maximum size of the trace file (in bytes) state - Enables or disables winhttp tracing Examples: set tracing trace-file-prefix="C:\Temp\Test3" level=verbose format=hex set tracing output=debugger max-trace-file-size=512000 state=enabled

Please note that you can use the “state” parameter to disable / enable the tracing. For example, “set tracing state=disabled” will disable the tracing.

Also, your process needs to have enough permissions to create the trace file, so it is recommended to specify a folder via the “trace-file-prefix” parameter that you know your process has write access to.

-Nesho Neshev

Content-Encoding != Content-Type

wndpteam — Mon, 21 Aug 2006 18:00:00 GMT

RFC 2616 for HTTP 1.1 specifies how web servers must indicate encoding transformations using the Content-Encoding header. Although on the surface, Content-Encoding (e.g., gzip, deflate, compress) and Content-Type (e.g., x-application/x-gzip) sound similar, they are, in fact, two distinct pieces of information. Whereas servers use Content-Type to specify the data type of the entity body, which can be useful for client applications that want to open the content with the appropriate application, Content-Encoding is used solely to specify any additional encoding done by the server before the content was transmitted to the client. Although the HTTP RFC outlines these rules pretty clearly, some web sites respond with "gzip" as the Content-Encoding even though the server has not gzipped the content.

Our testing has shown this problem to be limited to some sites that serve Unix/Linux style "tarball" files. Tarballs are gzip compressed archives files. By setting the Content-Encoding header to "gzip" on a tarball, the server is specifying that it has additionally gzipped the gzipped file. This, of course, is unlikely but not impossible or non-compliant.

Therein lies the problem. A server responding with content-encoding, such as "gzip," is specifying the necessary mechanism that the client needs in order to decompress the content. If the server did not actually encode the content as specified, then the client's decompression would fail.

Here is a potentially over-simplified example:

Windows Vista Networking Rocks!
Jvaqbjf Ivfgn Argjbexvat Ebpxf!

If I mistakenly claim that string a) has been encoded using the simple ROT-13 obfuscation scheme when in actuality it has not, then the decoded message b) will be very different than the intended message.

Since the AI engine for WinINet isn't yet ready for production (joke), we try and work-around these non-compliant server responses but that isn't the right long-term approach. The fix and the ask, is for web server, extension and application authors to test their servers to see if they exhibit this behavior and if so fix their implementations before we remove our client-side hacks.

To test your server for compliance, issue a simple HTTP 1.1 request, including the "Accept-Encoding: gzip" for a .gz file and inspect the headers. If you see Content-Encoding: x-gzip or gzip, then the server is either gzip-encoding the already gzipped file or it is misstating that the content has been encoded by the server before transmission and therefore perpetuating client HTTP stacks, such as WinINet, having to absorb and hide this bad server behavior.

-Billy Anders

Large Request Payload Support in WinHttp for Windows Vista

wndpteam — Tue, 08 Aug 2006 18:00:00 GMT

If you have used WinHttp to upload data to a server, you probably noticed that the total payload length parameter (dwTotalLength in WinHttpSendRequest) is of type DWORD, which is a 32 bit unsigned number. This limits the WinHttp apps to uploading 4GB of data, which could become a limitation in certain scenarios.
A natural way to work around this limitation is to try to "chunked" encode the request payload, but there was a problem with WinHttp always appending a Content-Length header even if the app specifies a Transfer-Encoding: Chunked header, which causes many servers to reject the request.

Support > 4GB uploads using "Content-Length" in Windows Vista

In Windows Vista, WinHttp is getting an update in this category. First, applications can specify a Content-Length > 4GB. To do that, they have to manually append a Content-Length header with the desired value. WinHttp will monitor for this header and if it is present and its value is bigger than 2^32 it will use it as an indicator of the total request payload size and will ignore the dwTotalLength parameter. WinHttp will internally store the header value in a ULONGLONG, which is a 64 bit unsigned variable.

Support for "chunked" encoding the request payload in Windows Vista

Another WinHttp update for Windows Vista is that applications now can chunk encode the request data. To do that applications have to specify a non- "identity" "Transfer-Encoding" header (say "Transfer-Encoding: Chunked"), in which case WinHttp ignores the dwTotalLength parameter of WinHttpSendRequest API. In this mode of operation applications must not specify any optional data via WinHttpSendRequest call; attempting to do so will result in ERROR_WINHTTP_INVALID_PARAMETER. All entity body posting must be done via WinHttpWriteData API. Applications should also generate the last zero length chunk and send it via WinHttpWriteData API to terminate the upload operation since WinHttp is oblivious to how you are sending the entity body data. Calling WinHttpReceiveResponse tells WinHttp that you are done sending data. For more about chunk encoding please read the corresponding section in the HTTP/1.1 RFC.

There are a couple important notes for both styles of usage. First, applications need to be prepared to handle the ERROR_WINHTTP_RESEND_REQUEST return code in case WinHttp needs to resend the request (due to redirects and / or auth challenges). Since you will be using multiple WinHttpSendRequest and WinHttpWriteData calls, WinHttp won't be able to resend the entire request on your behalf like you might be used to when only calling WinHttpSendRequest. You should also be careful that WinHttpReceiveResponse can also pass back the resend return code. Second, in the case a POST request is redirected to a GET request (e.g. 302 response), WinHttp will automatically remove or reset the application specified "Transfer-Encoding" and/or Content-Length headers.

As always, we want your feedback. Please let us know what you think about this new functionality and whether you want to see some code samples on how to upload large payloads using WinHttp.

-Nesho Neshev

WinINet and WinHTTP IPv6 Support in Web Proxy Auto-Discovery (WPAD) scripts enabled in Windows Vista

wndpteam — Wed, 19 Jul 2006 01:06:00 GMT

Hi, my name is Jonathan Silvera and I am the WinINet and WinHTTP Program Manager. Today I would like to talk to you about changes we have made to add IPv6 support in the WinINet and WinHTTP WPAD helper functions.

The explosion of the Internet in the late 1990’s has caused an unexpected scarcity of IPv4 addresses, with the pool depleting on a daily basis. IPv6 provides a solution to this problem and although it is currently not widely deployed, its use will definitely become more prevalent in the future. WPAD is a protocol that allows web clients to automatically detect what the correct proxy configuration should be for their outgoing traffic. This is very useful for corporate deployments because it allows IT administrators to setup complex scripts that can route traffic for all clients to specific proxies based on the target server the clients are attempting to connect to. WinINet and WinHTTP support WPAD helper functions as defined by the Navigator Proxy Auto-Config (PAC) File Format specification, which has become a defacto standard. Unfortunately this specification was written in 1996 and does not define what the function behaviors should be when a WPAD script is deployed in an IPv6 capable network.

Here at Microsoft we are aware that IPv6 is the wave of the future and as part of a Windows wide push, we have required that all of our components support dual stack (IPv4 and IPv6) and IPv6 only networks. The first customer to approach us asking for IPv6 support in WPAD was our internal IT department after encountering issues with the IPv4 script dependency of their current deployment. When designing a solution to enable this scenario for Windows Vista, our team recognized the importance of providing a backwards compatible solution for IT administrators in order to avoid breaking the large number of existing corporate deployments with IPv4 script dependencies.

In order to meet our customer’s needs and support IPv6 without affecting existing deployment, we have added 6 new helper class functions as an extension to the Navigator Proxy Auto-Config (PAC) File Format specification and also added a new IPv6 capable function called FindProxyForURLEx that administrators can implement in the WPAD script.

New Proxy Helper API Definitons:

In order to take advantage of the IPv6 enabled functions, IT administrators must define within their WPAD script a function called FindProxyForURLEx (url, host) which will replace the legacy FindProxyForUrl (url, host) function. Only from the new FindProxyForURLEx function will administrators be able to execute the new functions.

We also attempted to simplify work for developers, by aligning our functions to return different types of IP addresses in the same order of preference as other networking components, specifically IPv6 addresses followed by IPv4 addresses (i.e. current behavior for Winsock’s getaddrinfo(..) function).

The following tables explain the differences between the new WPAD helper functions and the legacy WPAD helper functions. The new functions are marked with a *

Functions	Input	Output	Reason for Change
dnsResolve	Host	IPv4 address	Ex function will return a list of IPv6/IPv4. Necessary since IPv6 or IPv4 addresses can have multiple unicast addresses for a single interface
dnsResolveEx*	Host	List of IPv6/IPv4 addresses

Functions	Input	Output	Reason for change
isResolvable	IPv4 host	TRUE / FALSE	The Ex function will return TRUE if a host can resolve to an IPv6 or IPv4 address. The legacy function only returns TRUE if the host resolves to an IPv4 address
isResolvableEx*	IPv6/IPv4 host	TRUE / FALSE

Functions	Input	Output	Reason for change
myIPAddress	none	IPv4 address	Ex function will return a list of IPv6/IPv4. Necessary since IPv6 or IPv4 addresses can have multiple unicast addresses for a single interface
myIPAddressEx*	none	List of IPv6/IPv4 addresses

Functions	Input	Output	Reason for change
isInNet	Host, Dot separated IP address pattern, IP address Mask	TRUE / FALSE	Provide an IP version agnostic way to find if an IP address is in a given subnet. Also, the mask notation in IPv4 is deprecated.
isInNetEx*	IP Address IP Prefix	TRUE / FALSE

Functions	Input	Output	Reason for change
sortIPAddressList*	List of IPv6/IPv4 addresses	Sorted List of IPv6/IPv4 addresseslist of IPv6/IPv4 addresses	There is no counterpart legacy function because legacy functions only returned a single IPv4 address, therefore there was no need to sort

Functions	Input	Output	Reason for change
getClientVersion*	None	WPAD engine version number	Currently this function returns version 1.0. We added this function to allow IT administrators to update their WPAD to work with different versions of the WPAD engine without causing breaks to their existent deployment.

Again, see the extension spec for more details.

We are truly proud of our work extending the Navigator Proxy Auto-Config (PAC) File Format specification to work with IPv6 addresses while ensuring backwards compatibility, as we believe these changes will prove useful current and future IPv6 users. These changes are available for WinINet/WinHTTP in Windows Vista starting in Beta 2, for WinINet on XP and Windows 2003 through IE7 starting in Beta 2 and will be available in a future release of the .Net Framework’s system.net. We would love to hear feedback from the community regarding these changes and if you are planning to deploy a WPAD script in an IPv6 network please let us know about your experience.

Thanks
-Jonathan Silvera

Wanted: Developer feedback for our "Next Generation" client HTTP stack

wndpteam — Tue, 06 Jun 2006 22:48:00 GMT

As we begin the planning phase for our "Next Generation" client HTTP stack, we would love to hear from developers using our existing APIs (WinINet and WinHTTP). Please help us understand what your experience has been so far and what you would like to see in any future releases by filling out this survey.

Thanks

-Jonathan Silvera

WNDP Connect Site gets an upgrade!

wndpteam — Tue, 06 Jun 2006 19:32:00 GMT

Last year we setup a small site on connect.microsoft.com in order to let our blog readers, developers and users file bugs, make suggestions and get some conntent like whitepapers and samples early. The downside to the site was that you couldn't easily deep link and it required a Windows Live (aka Passport) login. Well the folks at connect.microsoft.com have launched a new version of connect that enables access to much of the site without a login including readonly access to the bugs filled there much like the popular MSDN Product Feedback Center.

Check it out: http://connect.microsoft.com/WNDP

-- Ari Pernick

WinHttp Configuration for Windows Vista Beta 2 - Part 4 Client Certificates

wndpteam — Sat, 13 May 2006 03:00:00 GMT

In Part 1, Part 2 and Part 3 of this series I discussed the tools used to configure WinHttp today, introduced the changes happening for Windows Vista and how to set up proxies and tracing. In this post I’m looking at the client certificate settings. Again as a reminder, this is how it is for Windows Vista Beta 2 and can change some before Vista RTM.

First, some background. WinHttp developers are hitting a common problem when trying to use client certificates in middle-tier scenarios. Typically in those cases client certificates are installed in the Local Machine certificate store so that different user accounts can access them. The problem is that by default, only administrators and the account that imported the certificate has access to the certificate’s private key. This prevents the middle-tier code from using the certificate to perform client authentication.

To solve this problem, WinHttp shipped winhttpcertcfg.exe tool, which for Windows Server 2003 was part of Windows Server 2003 Resource Kit Tools. The tool allows administrators to import client certificates and to manage the accounts that have access to the certificate’s private key.

Winhttpcertcfg.exe is being deprecated for Vista. The ability to manage the access to the certificate’s private key (for the certificates in the Local Machine store) is now built into the Certificates Microsoft Management Console (MMC) snap-in.

Here is how to get to the UI:

From the start menu or command line prompt, type mmc.exe, select File | Add/Remove Snap-in…, and add the “Certificates” snap-in for the Local Computer account. You could open certificates snap-in by typing “certmgr.msc” but it will open the Current User store. Note also that you can save the MMC configuration for later use.

To configure the accounts with access to the certificate’s private key, expand the tree view until you see the certificate (say “Certificates (Local Computer)\Personal\Certificates”), right-click on the certificate and select “All Tasks”, “Manage Private Keys…”:

This will open a standard permissions dialog from where you can manage the access to the certificate’s private key.

In case you need to import certificates you can use the same Certificates snap-in (right-click on the certificate store and select “All Tasks”, “Import…” or you can use the CertUtil command line tool to do it programmatically (type “certutil -importPFX -?” to see the usage).

We want your feedback!

This post is the last one of the WinHttp Configuration for Vista series.

Please let us know what you think about the new WinHttp configuration story. Please send us your comments or questions, especially if you see yourself being blocked because of a missing functionality.

--Nesho Neshev
Software Design Engineer / Test
Web Transports Team, Windows Networking

WinHttp Configuration for Windows Vista Beta 2 - Part 3 Tracing

wndpteam — Wed, 10 May 2006 08:40:00 GMT

In Part 1 and Part 2 of this series I discussed the tools used to configure WinHttp today, introduced the changes happening for Windows Vista and how to set up proxies. In this post I’m looking at the Tracing settings. Again as a reminder, this is how it is for Windows Vista Beta 2 and it is likely to change some before Vista RTM.

After running netsh and going to the winhttp context, we switch to the tracing context by typing “tracing”:

netsh winhttp>tracing

netsh winhttp tracing>?

The following commands are available:

..

.. (Skipping the inherited commands)

..

Commands in this context:

?              - Displays a list of commands.

config         - Configures WinHTTP tracing parameters.

disable        - Turns off WinHTTP tracing.

dump           - Displays a configuration script.

enable         - Turns on WinHTTP tracing.

help           - Displays a list of commands.

reset          - Resets WinHTTP trace parameters to default.

show           - Displays current tracing parameters.

Again the functionality here is similar to the WinHttpTraceCfg.exe tool with the addition of the “dump” command that creates a script with the current tracing settings which can be executed later to restore those settings on the current or another machine.

Let’s look at the current tracing settings:

netsh winhttp tracing>show

WinHTTP trace configuration not set.

You can easily disable or enable tracing by just typing “disable” or “enable”:

netsh winhttp tracing>disable

    Tracing is disabled.

netsh winhttp tracing>enable

Current WinHTTP Tracing settings:

    Tracing is enabled.

    Trace File Prefix: (none)

    Trace Output: file

    Trace Level: default (headers and top-level APIs only)

    Network Traffic Format: ansi

    Maximum size of trace file (in bytes): 65535

Note that “enable” sets some default tracing parameters.

You can use the “config” command to set some different values:

netsh winhttp tracing>config trace-file-prefix="C:\Temp\Test3" format="ansi" output=debugger level="verbose"

    Tracing is updated.

Current WinHTTP Tracing settings:

    Tracing is enabled.

    Trace File Prefix: C:\Temp\Test3

    Trace Output: debugger

    Trace Level: verbose (headers, APIs, and entity body)

    Network Traffic Format: ansi

    Maximum size of trace file (in bytes): 65535

If you have used WinHttpTraceCfg.exe before you probably noted a slight difference in the parameters. WinHttpTraceCfg.exe uses two parameters, -s and -t, to specify whether or not to trace the payloads (and if included, as Hex or ANSI) and whether or not to include the top level API traces respectively. The config command has a more clear separation by allowing you to specify a level (default – no payloads, verbose - include payloads) and logging format for the network traffic data (Hex or ANSI).

Again, if you need to get a help on a command, just type it with question mark after it.

Next time I will go into a bit more detail about client cert configuration.

-- Nesho Neshev

WinHttp Configuration for Windows Vista Beta 2 - Part 2

wndpteam — Tue, 09 May 2006 03:56:00 GMT

In Part 1 of this series I discussed the tools used to configure WinHttp today and introduced the changes happening for Windows Vista. In this post I’m looking at the Proxy settings. Again as a reminder, this is how it is for Windows Vista Beta 2 and it is likely to change some before Vista RTM.

After running netsh and going to the winhttp context, we switch to the proxy context by typing “proxy”:

netsh winhttp> proxy
netsh winhttp proxy>

Here is the list of available commands in that context:

netsh winhttp proxy>?

The following commands are available:

…
… (Skipping the inherited commands …)
…

Commands in this context:
?              - Displays a list of commands.
dump           - Displays a configuration script.
help           - Displays a list of commands.
import         - Imports proxy setting from IE.
reset          - Resets WinHTTP proxy setting to DIRECT.
set            - Configures WinHTTP proxy setting.
show           - Displays current WinHTTP proxy setting.

You can use “show” to view the current settings, “set” to set the proxy settings and “import” to import current user’s Internet Explorer proxy settings. If you’ve used proxycfg.exe you will find that this context provides the same functionality. The only exception is “dump”, which creates a Netsh script with the current settings and can be executed later (on the same machine or different one) to set those settings.

Let’s start by displaying the current proxy settings:

netsh winhttp proxy>show

Current WinHTTP proxy settings:

Direct access (no proxy server).

Now let’s set the proxy server for HTTP sites to “myproxy” (port 80 by default), proxy server for HTTPS sites to “sproxy” (port 88) and set the bypass list to “*.foo.com”:

netsh winhttp proxy>set proxy-server="http=myproxy;https=sproxy:88" bypass-list=
"*.foo.com"

Current WinHTTP proxy settings:

Proxy Server(s) : http=myproxy;https=sproxy:88
Bypass List : *.foo.com

To reset the proxy settings to “direct” (not to use proxy servers), just type “reset”:

netsh winhttp proxy>reset

Current WinHTTP proxy settings:

Direct access (no proxy server).

Another useful command is to import the proxy settings for the current user in Internet Explorer (note that different users may specify different proxy settings in IE):

Current WinHTTP proxy settings:

Proxy Server(s) : ieproxy:80
Bypass List : <local>

Again, if you need to get a help on a command, just type it with question mark after it.

Next time I will go into a bit more detail about tracing configuration.

--Nesho Neshev

WinHttp Configuration for Windows Vista Beta 2 - Part 1

wndpteam — Sat, 06 May 2006 01:45:00 GMT

WinHttp for Windows XP and Windows Server 2003 comes with variety of tools that allow the users and system administrators to configure the default proxy settings (ProxyCfg.exe), tracing settings (WinHttpTraceCfg.exe) and configure client certificates (WinHttpCertCfg.exe).

ProxyCfg.exe has been part of the operating system, while WinHttpTraceCfg.exe and WinHttpCertCfg.Exe have to be downloaded separately as part of the Windows Server 2003 Resource Kit Tools.

To avoid the need of tools that don’t ship with Windows and to make the user experience more consistent with the other networking components, ProxyCfg.exe and WinHttpTraceCfg.exe are deprecated for Windows Vista and replaced with Net Shell (Netsh) extensions. WinHttpCertCfg.Exe is deprecated as well and its functionality is integrated in the new Certificates MMC snap-in.

If you are not familiar with Netsh, you can take a look at Windows XP online help (here is a good link). In this post series we will go over some samples on how to configure the WinHttp proxy, tracing settings and client certification settings. Please note that the samples describe the current behavior in Windows Vista Beta 2 and that the command syntax is likely to change a bit for Vista RTM.

To start, you can load up netsh on a Vista CTP build and check it out. The new context that WinHttp introduces is “WinHttp”. You can get to it by just typing “winhttp” from the root netsh context:

C:\> netsh
netsh> winhttp
netsh winhttp>

From here there are two nested contexts available:

proxy - Configures proxy settings in WinHTTPtracing - Configures tracing in WinHTTP

Note that at any point you can type “?” to get the list of supported commands. Also, typing “command ?” will show all the parameters for that command.

Next time I will go into a bit more detail about the proxy configuration.

-- Nesho Neshev

What's next on the client HTTP stack front

wndpteam — Fri, 24 Mar 2006 03:00:00 GMT

http://www.microsoft-watch.com/article2/0,2180,1940567,00.asp
Hachamovitch acknowledged Microsoft already is building the next two versions of IE. He declined to offer guidelines on delivery schedules or feature sets, other than to say one of the two versions will include "a complete reworking of the networking stack."

That would be us. We are going to be busy for awhile :)

-- Ari Pernick