IIS Insider - February 2005

February 2005

Top Questions and Answers on Internet Information Services

By Brett Hill

TCP/IP Connection Drops When Response.buffer (in ASP) Is Set To False

Fac1

Q We have an ASP application running on our IIS 6 server that sends important information to our users in "spurts." We want the user to get the information as soon as it is available, rather than wait for the ASP page to complete. To do this on IIS 5, we set the Response.buffer property to FALSE in ASP. However, we have noticed that in IIS 6, this ends the TCP/IP connection to the client which results in unpredictable behavior for our application.

A

For readers that aren�t familiar with Response.buffer in ASP (Active Server Pages), Response.buffer is a property that when set to true (the default in IIS 5 and 6), causes ASP to hold off sending the results from rendering a script until the entire ASP page has run. In a small number of applications, when response.buffer is set to true it can appear as if the application is running slowly as the user is not sent any information until the page is completed. Long-running pages or pages with loops that retrieve data from a data source and then return the information are examples of the kinds of code that exhibit this behavior. One potential solution to these issues is to set Response.buffer to false. The user would see the information as it is rendered rather than waiting on the entire page.

I want to be very clear that there are not many situations where setting Response.buffer to false is beneficial. Before you go that far, you should have exhausted trying to use the Response.Flush method to push content to the client when your application has information the user needs right away, but the page is not finished processing. Using Response.Flush lets you keep buffering enabled, yet control exactly when the response buffer is sent to the client.

Having said all that, the behavior you�re reporting, where the client�s TCP/IP connection is being dropped when Response.buffer is false, is actually a bug in IIS 6. The TCP/IP connection should not be dropped and you can fix this with an update available from Product Support Services (PSS), as detailed in https://support.microsoft.com/default.aspx?scid=kb;EN-US;834027 (or SP1 for Windows Server 2003 when it becomes available).

For a discussion of these topics with ASP.net, see https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenetchapt06.asp. The fix only applies when using ASP, as opposed to ASP.net.

Hiding the IIS Server�s IP Address

Fac2

Q When a user connects to our IIS server, the IP address of the server is sent to the user�s system as part of server�s response. How can we hide the server IP address from the user?

A This is a potential security issue that you should review for all your IIS servers. By default, IIS 4, 5 or 6 will reply to a client request with something that resembles the following:

HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Content-Location: https://10.1.1.1/Default.htm Date: Thu, 18 Feb 1999 14:03:52 GMT Content-Type: text/html Accept-Ranges: bytes Last-Modified: Wed, 06 Jan 1999 18:56:06 GMT ETag: "067d136a639be1:15b6" Content-Length: 4325

As you said, the IP address of the server is revealed in this example. This is not desirable in many circumstances where the IP address of the server is on a private network behind a NAT device or reverse-proxy, as it provides a would-be attacker with information about the network infrastructure.

You have several choices to remedy this situation. With IIS 5 (and IIS 4), set the Metabase property W3SVC\UseHostName property to True. Note that you must stop and start IIS in order for this change to take effect.

On IIS 6, until Windows Server 2003 SP1 is released, you will need a hotfix available from PSS. You can find details on this IIS 6 hotfix, including support contact numbers, at https://support.microsoft.com/?id=834141.

Another way to prevent users from seeing the server IP address is to use ASP or ASP.net instead of static HTML pages (.htm or .html) and create a custom header that sends back a specific Content-Location field.

For IIS 4, 5, and 6.0, you can set the web site to use a host header to respond to any requests for content. When a host header is used on a web site, the IP address of the server is not returned in the Content-Location field. For additional information about how to use host header names to host multiple sites from one IP address, read article 190008 in the Microsoft Knowledge Base.

Site ID Creation Values Have Changed

Fac3

Q When creating web sites in IIS 6, the site ID numbers are quite large and can�t be predicted. In IIS 5, when you created a web site, the site ID was the next available integer so it was easier to manage. Typing in numbers like 155406402,204553352 as part of the paths for scripts, batch processes, etc., is much more difficult than integers such as 1,2,3, and so on. What is the rationale behind this change between IIS 5 and IIS 6, and is there some way to control it?

A The site ID is the number that IIS uses internally to uniquely identify a web site. In other words, when you create a web site, you give it a name such as "Accounting Intranet," but IIS does not use that name at all. Instead, a number called a site ID is assigned to the web site. The site ID and other properties and values that make up the web site�s configuration are stored in the Metabase and are automatically maintained.

For many IIS administrators, their first interaction with the site ID is when they attempt to locate the logfiles for a web site. Shown in Figure 1 is the location for the IIS log files on an IIS 6 server.

The Log file name is "W3SVC" plus the site ID. This is true in IIS 5 and in IIS 6. Can you tell from looking at the listing of log file folders (see Figure 2), the name of the associated web sites?

In general, the answer is no except for "W3SVC1" which is the Default Web Site.

Scripting is another reason you will need to know the site ID�s. That�s too big a topic for us to tackle in this IIS Insider column, but here�s a brief overview.

Just as there are paths to filenames (C:\<directory>\<filename>), there are paths to locations in the Metabase (W3SVC\<Site ID>\<Property name>). For example, if you were to refer to the location where the web site name was stored in the Metabase for the default web site, that would be W3SVC/1/ServerComment. You can query or change any values in the Metabase using a script or ADSUTIL. For more information about the Metabase, see https://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/featured/iis/default.mspx.

For this and other reasons (such as writing a script to edit properties in the Metabase), you will need to know how to associate any particular web site with its site ID.

In IIS 5, the easiest way in the Internet Services Manager console is to go to the Logging Properties window, as shown in Figure 1. In IIS 6, the site ID is shown in the Internet Information Services Manager along with the site name and IP address. (See Figure 3.)

Now that we�ve covered what a site ID is, why we need to know it, and how to associate the site ID with a web site, we�ve come full circle back to the question.

As you noted, in IIS 5, site IDs are created incrementally whereas IIS 6 creates big and apparently random numbers for the site ID. However, there is a method to the madness. The site ID in IIS 6 is generated from the web site name. If you create a site called the "Accounts Receivable Intranet," deleted the site, and recreated it, it would have the same site ID! In IIS 5, this would not be the case. This particular feature is crafted for IIS customers that have web farms where multiple servers exist that are content replicas of each other. In this way, the site ID�s for all the web sites in the farm are the same, for the same web sites. For example, if there are three IIS 6 servers in the farm, all with a web site named "Company Extranet," the site ID would be the same on all three IIS servers. This places the logfiles and IIS Metabase properties in the same file and ADSI path respectively making it easier for scripted routines to execute on all servers across the farm.

If this feature is more of a problem than a benefit to you, you can disable it and return to the IIS 5 style site ID algorithm. Add IncrementalSiteIDCreation to the following registry subkey:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InetMgr\Parameters

For More Information

Submit your questions to the IIS Insider. Selected questions along with the answers will be posted in a future IIS Insider column.

For a list of previous months' questions and answers on IIS Insider columns, click here

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as is," without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.