Consider the following scenario:

You use Windows Integrated authentication in a Microsoft Internet Information Services 6.0 (IIS 6.0) Web application environment.

You use Microsoft Internet Explorer 6 to access a Web application that is hosted on IIS 6.0.

In this scenario, you may experience poor Web application performance.

Note The problem does not occur if Anonymous authentication is used as the authentication protocol. This problem also does not occur if the client browser is a browser other than Internet Explorer 6, such as Mozilla Firefox.

This problem occurs because the Internet Explorer 6 client regularly resets the TCP connections.

If you analyze a network trace that is captured during the poorly-performing communication between the client and the server, the network trace shows that the TCP resets will occur after the client receives a 200 response for the resource that the client has requested. The client makes the GET requests with an ETag HTTP header and value. When the server that is running IIS 6.0 receives the request, it compares the ETag value and finds that the ETag value matches the requested file’s current value, except for the change number.

Note ETag headers appear in the following format:

Filetimestamp:ChangeNumber

For example, the Internet Explorer client sends a request with an ETag value of 0222d5bffcbc41:301a, and then the server will send an HTTP 200 response with an ETag value of 0222d5bffcbc41:3246.

The Filetimestamp number in the request is the same number that IIS 6.0 considers to be the current value for the request resource. But because the ChangeNumber number in the request is different, IIS 6.0 sends back the current version of the file instead of telling Internet Explorer to serve its own cached copy. There is specific code in Internet Explorer that compares the Filetimestamp on a 200 response with the Timestamp of the locally-cached copy. The connection is reset if they are the same number. This is because the Internet Explorer client expects to receive a 304 status report if the content is the same.

In other words, IIS 6.0 sends a 200 response because it considers the different change numbers to mean that the resource that is requested by the client and by the client’s pre-existing version of this resource that resides in the browser cache are not the same versions. However, Internet Explorer considers them to be the same versions because the Filetimestamp is the same. Additionally, Internet Explorer believes that it is receiving the 200 response in error. In this scenario, Internet Explorer resets the TCP connection.

If you are using a Microsoft Windows Server 2003-based computer

To work around this problem, we recommend that you hard code the change number on the Web server and that you synchronize the file version for all the Internet Explorer clients. All the Internet Explorer clients will have versions of all the different files that are required for the application. You must make sure that the server and all the clients are synchronized.

Note If you are running in an IIS 6.0 Web farm environment, you will have to hard code the same change number for all the servers that are running IIS 6.0 in the farm.

To synchronize the change number values between the clients and the server, follow these steps.

1.

Manually hard code the ETag value in the IIS 6.0 metabase The ability to modify the ETag change number on IIS 6.0 is available in Windows Server 2003 Service Pack 1 (SP1). Note You may experience a problem when you change the ETag value, and you must install a hotfix to fix this problem. For more information about the hotfix, click the following article number to view the article in the Microsoft Knowledge Base: The value in the ETAG field is updated when you modify a metabase property in IIS 6.0 After you install the hotfix, you can manually hard code the ETag change number. However, the setting for the ETag change number is not exposed to the Active Directory Service Interfaces (ADSI) namespace. Therefore, you must use the Metabase Explorer tool to set the value by property ID. To download and install Metabase Explorer, visit the following Microsoft Web page: http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/993a8a36 -5761-448f-889e-9ae58d072c09.mspx (http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/993a8a36-5761-448f-889e-9ae58d072c09.mspx?mfr=true) Note Metabase Explorer is included in the IIS 6.0 resource kit. To manually hard code the ETag change number, follow these steps: a. Open Metabase Explorer, expand LM on the left pane, and then expand W3SVC. b. Double-click the ID 2039 record on the right pane. c. Type a number from 1 through 4294967295 in the Value box. The actual number that you use is irrelevant, as long as it is within the previously mentioned range. For more information, visit the following Microsoft Web page: http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/ef7f9d58- 2a96-4bd8-8ac1-2a67b43284f1.mspx (http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/ef7f9d58-2a96-4bd8-8ac1-2a67b43284f1.mspx) d. Click Apply, and then click OK. Note If you are running IIS 6.0 servers in an IIS 6.0 Web farm environment, repeat steps 1a through 1d on all the IIS 6.0 servers in the farm. Make sure that you add the same change number value on all servers.

2.

Clear the client browser cache in Internet Explorer If there are too many client browsers to manually clear the cache, you can select Enable Content Expiration in IIS 6.0 and then specify that the content expires immediately. In this scenario, you need to leave Enable Content Expiration turned on for only as long as it takes for all clients have fresh content. Then, you need to turn off Enable Content Expiration to give Internet Explorer a chance to serve cached content again. To enable content expiration, follow these steps: a. Open Internet Information Services. b. Expand LocalMachine on the left pane, and then click Web Sites. c. Right-click Web Sites, and then click Properties. d. On the HTTP Headers tab, click to select the Enable Content Expiration check box, and then click the Expire Immediately option. e. Stop and restart all the IIS 6.0 services. Note A client may have to make two requests for a resource after the Enable Content Expiration check box is enabled to update the Internet Explorer cache.

If you are not using a Windows Server 2003-based computer

To work around this problem, enable the Enable Content Expiration option in IIS 6.0 by using the procedure that is described in the "Clear the client browser cache in Internet Explorer" section, and leave it on. Additionally, turn off caching in Internet Explorer or set cache control headers in the Web application. For more information about how to prevent Web caching, click the following article number to view the article in the Microsoft Knowledge Base:

This problem was corrected in Microsoft Internet Explorer 7.

If you analyze a Network Monitor trace that is captured on the client or on the server, and this trace is involved in the performance scenario, you see the following sequence:

1.	The client sends the GET request to the server that is running IIS 6.0, and the request includes an If-None-Match header with a Filetimestamp:ChangeNumber value. This request resembles the following: HTTP: GET Request from Client HTTP: Request Method =GET HTTP: Uniform Resource Identifier =/MARRS/webService.htc HTTP: Protocol Version =HTTP/1.1 HTTP: Accept = */* HTTP: Accept-Encoding =gzip, deflate HTTP: If-Modified-Since =Tue, 16 Nov 2004 17:11:48 GMT HTTP: If-None-Match ="0222d5bffcbc41:301a" HTTP: User-Agent =Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1 HTTP: Host =nnoma-wwapp02m HTTP: Connection =Keep-Alive HTTP: Authorization =Negotiate TlRMTVNTUAADAAAAGAAYAG4AAAAKAQoBhgAAAAoACgBIAAAAEgASA HTTP: Cookie =ASP.NET_SessionId=uqnwgpygpf0dh2iwysznat55 Note Some of the HTTP variables in these examples may be different in your environment.
2.	The server receives the request and sends a 200 response together with the data that is requested. Because the client sent the If-None-Match header, IIS 6.0 has to include an ETag response header and header value in its response. This response resembles the following: HTTP: Response to Client; HTTP/1.1; Status Code = 200 - OK HTTP: Protocol Version =HTTP/1.1 HTTP: Status Code = OK HTTP: Reason =OK HTTP: Content-Length =51622 HTTP: Content-Type =text/x-component HTTP: Last-Modified =Tue, 16 Nov 2004 17:11:48 GMT HTTP: Accept-Ranges =bytes HTTP: ETag ="0222d5bffcbc41:3246" HTTP: Server =Microsoft-IIS/6.0 HTTP: X-Powered-By = ASP.NET HTTP: Date =Tue, 27 Sep 2005 12:18:27 GMT HTTP: Data: Number of data bytes remaining = 1202 (0x04B2)
3.	The client receives the response. The response has an HTTP 200 status, instead of the HTTP 304 status that the browser was expecting. Therefore, the browser sends a TCP RST to reset the connection. It does this because Internet Explorer believes that the server sent the HTTP 200 status in error. The TCP RST resembles the following: TCP: Control Bits: .A.R.., TCP: Source Port = 0x0747 TCP: Destination Port = World Wide Web HTTP TCP: Sequence Number = 3840808344 (0xE4EE1598) TCP: Acknowledgement Number = 3150159894 (0xBBC3A016) TCP: Data Offset = 20 bytes TCP: 0101.... = Data Offset (20 bytes) TCP: ....0000 = Reserved bits TCP: Flags = 0x14 : .A.R.. TCP: ..0..... = No urgent data TCP: ...1.... = Acknowledgement field significant TCP: ....0... = No Push function TCP: .....1.. = Reset the connection TCP: ......0. = No Synchronize TCP: .......0 = Not the end of the data TCP: Window = 0 (0x0) TCP: Checksum = 0xF26C TCP: Urgent Pointer = 0 (0x0) For more information about the Transmission Control Protocol (TCP), visit the following Web page: http://www.faqs.org/rfcs/rfc793.html (http://www.faqs.org/rfcs/rfc793.html)