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
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.
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
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
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.
- 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 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: Note Metabase Explorer is included in the IIS 6.0 resource kit.
The value in the ETAG field is updated when you modify a metabase property in IIS 6.0
To manually hard code the ETag
change number, follow these steps:
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.
- 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.
- 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:
- Click Apply, and then click OK.
- 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 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.
- Open Internet Information Services.
- Expand LocalMachine on the left pane, and then click Web Sites.
- Right-click Web Sites, and then click Properties.
- On the HTTP Headers tab, click to select the Enable Content Expiration check box, and then click the Expire Immediately option.
- Stop and restart all the IIS 6.0 services.
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:
How to prevent Web caching in Windows 2000
Windows Internet Explorer 7 has been modified to correctly handle the ETag change number according to RFC 2616. However, if the ETag number is changed, Windows Internet Explorer 7 will download the complete file instead of canceling the connection. This behavior can slow the performance of Internet Explorer 7 compared to Internet Explorer 6.
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:
- 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:
Note Some of the HTTP variables in these examples may be different in your environment.
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
HTTP: Host =nnoma-wwapp02m
HTTP: Connection =Keep-Alive
HTTP: Authorization =Negotiate
HTTP: Cookie =ASP.NET_SessionId=uqnwgpygpf0dh2iwysznat55
- 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)
- 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:
For more information about the Transmission Control Protocol (TCP), visit the following Web page:
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)
Article ID: 922703 - Last Review: June 7, 2007 - Revision: 3.2
- Microsoft Internet Explorer 6.0
- Microsoft Internet Information Services 6.0