Microsoft KB Archive/922703

= You may experience poor Web performance when you use Internet Explorer 6 to try to access a Web application that is hosted on Internet Information Services 6.0 =

Article ID: 922703

Article Last Modified on 6/7/2007

-

APPLIES TO


 * Microsoft Internet Explorer 6.0
 * Microsoft Internet Information Services 6.0

-



SYMPTOMS
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.



CAUSE
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:



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  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  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  on a 200 response with the   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  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.  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:

900245 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 to install Metabase Explorer, visit the following Microsoft Web page:

http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/993a8a36 -5761-448f-889e-9ae58d072c09.mspx

Note Metabase Explorer is included in the IIS 6.0 resource kit.

To manually hard code the ETag change number, follow these steps:  Open Metabase Explorer, expand LM in the left pane, and then expand W3SVC. Double-click the ID 2039 record in the right pane. If the ID 2039 record is not present, you must create it. To do this, follow these steps:  Right-click the W3svc node in the Metabase Explorer, point to Create New, and then click DWORD value. Set the identifier of the new DWORD to 2039 . Set the value of the new DWORD to 0 .</ol> </li> Type 0 in the Value box.

Note The number that you type inside the Value box must be from 0 through 4294967295. Additionally, all servers in the farm must have the identical number in the Value box. For more information, visit the following Microsoft Web page:

http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/ef7f9d58- 2a96-4bd8-8ac1-2a67b43284f1.mspx

</li> Click Apply, and then click OK.</li></ol>

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.</li> 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: <ol style="list-style-type: lower-alpha;"> Open Internet Information Services.</li> Expand  on the left pane, and then click Web Sites.</li> Right-click Web Sites, and then click Properties.</li> On the HTTP Headers tab, click to select the Enable Content Expiration check box, and then click the Expire Immediately option.</li> Stop and restart all the IIS 6.0 services.</li></ol>

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.</li></ol>

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 &quot;Clear the client browser cache in Internet Explorer&quot; 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:

311006 How to prevent Web caching in Windows 2000

<div class="status_section">

STATUS
This problem was corrected in Microsoft Internet Explorer 7.

<div class="moreinformation_section">

MORE INFORMATION
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: <ol>  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 :  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 =&quot;0222d5bffcbc41:301a&quot; 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. </li>  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 =&quot;0222d5bffcbc41:3246&quot; 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) </li>  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

</li></ol>

Additional query words: WIA NTLM windows integrated authentication poor performance TCP RST reset etag changenumber filetimestamp MD_ETAG_CHANGENUMBER

Keywords: kbtshoot kbprb KB922703

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.