WebTransports's WebLog : WinInet

Migrating

WebTransports — Wed, 20 Jul 2005 00:21:00 GMT

This blog is migrating to the WNDP blog. This one will stick around but won't be updated.

Cookies and P3P

WebTransports — Fri, 15 Jul 2005 04:34:00 GMT

Microsoft Monitor discusses a little bit about cookies and P3P after a Mossberg Wall Street Journal Column

Longhorn Networking Chat: Http, Winsock and QoS

WebTransports — Tue, 22 Mar 2005 20:52:00 GMT

Today was the Longhorn Networking Chat, I've organized some of the QA and will do a series of posts on different topics that came up. See the full transcript on Channel 9.

Http, winsock and QoS are the areas closest to me organizationally so I'll start here.
There were a two http stack questions:

Henry_MSFT (Expert):
Q: Windows XP reduces simultanious connections to a HTTP (Web) server by default to 2-4. Will this be changed in Longhorn? (e.g. 5 simultanious connections allowed)

A: You are referring to the client connection limit, correct? We are conformant to the HTTP standard RFC which specifies the 2 connections/client/server limit. It is possible to change the limit programatically but the default will be standards conformant.

Henry_MSFT (Expert):
Q: Is WinInet going to be depricated at somepoint for something more reliable?

A: We currently have WinHTTP, which is our preferred unmanaged client API. We are also investing in improving the stability of WinInet for browsing experiences.

A bunch of QoS questions:

Henry_MSFT (Expert):
Q: What about QOS in the home or even DRM based access control for consumer scenarios?

A: We will have support for QoS in the home - some of this has already shipped in Media Center versions of the OS. This includes bandwidth measuring & monitoring, admission control, & QoS diagnostics.

Henry_MSFT (Expert):
Q: Thansk Henry .. can you expand on QOS diagnostics ? is that more just self healing/event response kind of scenarios? (e.g. network slows down .. do action x ) or ..

A: More about telling you why your application doesn't work. For example, if you're trying to stream video off a server but the network bandwidth is chewed up for some other reason (a game, another video stream, etc) we'd like to be able to inform the user/application that they can't get the bandwidth they need, but if they shut down the activity on machine X they should be able to.

Of course, we're also investing in cooperative admission control protocols, so participating devices & machines will be able to avoid this problem.

Henry_MSFT (Expert):
Q: Are we seeing more adoption of QOS tagging in consumer devices ?

A: This will be more important as consumer networking devices become more important. We think this is key thing going forward and we are working with the industry to try and accelerate this.

Henry_MSFT (Expert):
Q: Will be there a possibility to easely configure bandwith limitations for applications, or if the pc is an ics host for computers?

A: Yes, programatically, or via group policies. Are you interested in a specific UI configuration for this?

Henry_MSFT (Expert):
Q: If I am streaming audio or video over the net and downloading will the download interupt the streaming or will it be clever enough to reduce the speed of the download ?

A: We are looking at this...some of this is dependent on the applications. We certainly support the APIs and framework needed to do this in LH if applications use them. This is part of our QoS support.

... and a winsock question:

Henry_MSFT (Expert):
Q: In LH, will Layered Service Providers (LSP) be done away with?

A: No, they will still be supported. However, we are making efforts to clean up the architecture, make it more stable & secure, and make it easier to write solid LSPs.

What can cause Wininet to return ERROR_INTERNET_CANNOT_CONNECT?

WebTransports — Wed, 16 Feb 2005 01:49:00 GMT

Glad you asked.
The following winsock errors get translated into ERROR_INTERNET_CANNOT_CONNECT:

WSAENETDOWN
WSAECONNREFUSED
WSAENETUNREACH
WSAENOTCONN

Learn more about these errors on the Windows Sockets Error Code page.

IE7 comming soon to Windows XP SP2

WebTransports — Wed, 16 Feb 2005 00:05:00 GMT

Bill Gates annouced IE 7 today at the RSA Conference:

Building on those advancements, Gates announced Internet Explorer 7.0, designed to add new levels of security to Windows XP SP2 while maintaining the level of extensibility and compatibility that customers have come to expect. Internet Explorer 7.0 will also provide even stronger defenses against phishing, malicious software and spyware. The beta release is scheduled to be available this summer.

It'll be great to get much of the realiability work we've done in WinInet out to the public.

Wininet Cache: Index.dat

WebTransports — Fri, 19 Nov 2004 05:33:00 GMT

Jeffdav continues his blogging about the WinInet Cache with a multiple posts on index.dat.

Wininet Cache Issues

WebTransports — Sat, 30 Oct 2004 04:34:00 GMT

Jeffdav's weblog has an entry on why view->source sometimes stops working and why you get forced to save some images as bmp when they really aren't. While you are waiting for the fix, the workaround we use on the Longhorn Wininet team is to lower our cache size down to something more reasonable. Mine is set to 60 Mb. Not to worry, this won't affect downloading large files.

The setting is available on Tools->Internet Options->Temporary Internet Files->Settings.

I believe that the default for the setting is based on the hard drive size, so you are more likely to run into the issues on a newer machine with a bigger hard drive partition.

Where to put the credentials?

WebTransports — Fri, 25 Jun 2004 23:44:00 GMT

Jon Udell looks a bit into credential management on Windows and gets a bit confused at what he finds. The problem is that there are domain/computer credentials and “Internet” credentials and they overlap a little bit. Domain/computer credentials are credentials that are useful for accessing resources controlled by a domain or computer, usually stuff like file shares and printers, the stuff windows has been using since Windows NT 4 (and earlier). “Internet” credentials are lot more varied. The two interesting types in this case are HTTP level authentication and forms based authentication. Forms based authentication is the type where you fill out a form on a web page and that logs you into a site. It’s the main way that people authenticate on the Internet Web today.

HTTP level authentication happens at a lower layer of the protocol stack then forms based authentication, and is recognizable as a type that results in a popup asking for credentials. In windows pervasive intranets this type of authentication is more common, especially since we can often avoid having to ask the user for their credentials, since they signed into the computer with them. HTTP level authentication supports a couple of different schemes, some of which are more secure then others. The schemes Kerberos and NTLM allow IE to use the domain/windows credentials to satisfy an HTTP auth challenge. This is where the two types of credentials mix a little.

The Credential Management feature that Udell is noticing is tied to the domain/windows notion of credentials (although ironically the main credential it tends to hold is passport’s one). You can be not joined to a domain, add credentials for that domain and have a single sign on type experience when communicating with resources (file shares/databases/websites) that belong to that domain. It’s a pretty handy feature in the windows networking world, especially, I’ve found, with a laptop that I bring to work but is not joined to the work domain, and authentication between machines in my house. The Credential Management APIs (starting in Windows XP) and the Data Protection APIs are a pretty secure way to store credential in windows (starting in Windows 2000), but the Windows XP version of WinInet, the component that handles the HTTP protocol and authentication for IE, only uses them for NTLM/Kerberos challenges. Credentials saved from the basic and digest authentication schemes are stored in an older component called PStore. Pstore doesn’t do as good of a job of protecting credentials as the Data Protection and Credential Management APIs do and as the warning on the API documentation suggests, it is likely to change or go away in Longhorn. In that timeframe WinInet will switch to use the better APIs for those types of credentials. As for Udell’s question #1, which asks why we don’t use the better APIs to store basic and digest authentication, my best guess is that the credential manager wasn’t really made to hold that type of credential well (you can’t input them from the GUI UI). And to answer question #2, this hasn’t changed in Windows XP SP2.

Even with the planned changes I referred to, you are still are far cry from centralized credential management that includes all web credentials. The credentials in the better store may still not show up in the GUI and forms based authentication is a completely different beast altogether. Sounds like a nice feature to integrate all of those in one gui for a user, and maybe an IE or a security pm will here the call and make it so, especially if the users ask for it.

Welcome to Window's Web Transports Blog

WebTransports — Wed, 25 Feb 2004 01:01:00 GMT

This is a collaborative Weblog from the Web Transports Team in Windows Networking. As a team we work on the http stacks in Windows; http.sys the kernel part of the IIS 6.0 Web Server (part of Windows Server 2003) and its own developer API, wininet.dll which is the client side HTTP stack at the heart of Internet Explorer, and winhttp.dll which is the client side HTTP stack favored by server applications relying on performance and reliability.

At this point we aren’t sure exactly what sort of information we will put up here, but it probably will be related to whatever we get asked in the comments and whatever we are working on that week. Please don’t hesitate to post a comment with any questions or topics you wish us to talk about in the future. A lot of it will be developer focused, some content will be end user focused (especially on the wininet.dll/IE side).

If you don’t know what an HTTP stack is, it’s a protocol stack that talks the W3C’s HTTP protocol on behalf of applications. That’s the main protocol used on the web. It’s gone through a few versions, from 0.9 to 1.0 and now 1.1. We’ll probably write an entry or point to some good references on what has changed over time in the protocol’s evolution.

By the way, my name is Ari Pernick, and I’m a test development lead for web transports. As we post over time you will get an introduction to some of the Developers, Testers, Program Management, Product Support and others who contribute to our team.

UPDATE: In the comments below I claimed that pipelinning would be in Longhorn Version of Winhttp. It was early in the product cycle and since then, for a number of reasons, the code changes to support pipelinning support didn't make it into the final release. Sorry for any confusion.