Why does IE keep closing out valid ports on a 200/OK response?
This is a very interesting issue, but rarely comes up and so it's hard to detect immediately. Let's begin...
An issue is opened up with Microsoft due to poor performance, in where IE seems to be closing out valid ports for not
particular reason. Traces are taken and it "low and behold", IE is closing out a port on a very valid 200/OK response from
the IIS server.
At this point the IE engineer is scratching his head, wondering what in the world is going on...
But wait, the engineer has an idea - reproduce the issue. That's a great idea! So the engineer does just that by getting
the details behind the issue, and sets up the behavior accordingly:
The customer has written a custom web application using Internet Explorer and Internet Information Server with integrated
authentication in an Active Directory environment. The poor performance is seen because IE is closing out connections after
every request to the server, and so re-authentication is happening over and over again even though Kerberos is being used
(similar to what you would see when using NTLM authentication as it is a port-based authentication method).
Unfortunately, the IE engineer is unable to reproduce the failing behavior even though the reproduction steps have been followed to the letter.
Since the IE engineer is unable to reproduce the undesired behavior, he decides to compare a failing network trace to a working
network trace (using his working reproduction). Interestingly enough, he finds a difference.
In the failing network trace, the 200/OK response ports that are being closed out are missing an important HTTP header. The missing header is one that determines the server type. For example:
Server: Microsoft-IIS/6.0
This is very interesting, indeed!
After making this determination, the IE engineer asks the customer to use the Fiddler tool to insert this exact header for every HTTP response coming from the IIS server.
Note: The Fiddler tool allows the manipulation of HTTP headers. So in this case. Using Fiddler, HTTP headers can be manipulated "before" IE has to chance to parse the headers in the 200/OK responses which are coming from the IIS server. This does require a custom script addition to the CustomRules.JS file that Fiddler uses for it's header manipulation:
class Handlers
{
...
public static RulesOption("Add Server Header")
var m_serverheader: boolean = false;
...
static function OnBeforeResponse(oSession: Session)
...
if (m_serverheader){
oSession.oResponse.headers.Add("Server", "Microsoft-IIS/6.0");
}
Note: Adding the the script in this way will set the value to OFF, by default. You will still have to go into the UI and turn it ON under the "Rules" menu option once you have saved the changes to the CustomRules.JS file.
Back to business...
Once the SERVER header is added to the IIS Server responses, the performance problem goes away as the ports are no longer being closed by IE.
Of course, this isn't a solution. It only proves the point that the header is manipulating the behavior seen with Internet Explorer. A reason behind the behavior must still be found.
After more research and asking the customer questions about his IIS configuration, it is determined that URLscan is being used on the Web Server.
Below is a link with more details on URLscan:
From the documentation, it's clear that URLscan is purposely removing the SERVER header from the IIS 200/OK responses. So now we know the reason for the missing header, but we still don't know understand why IE is closing out the port when the header is missing.
To find out this information, a code-level review is required. From the code review, it is determined that the behavior is intentional - WHAT?!
As it turns out, there is actual logic in the source code that closes out a 200/OK response within an authentication context (in other words, during the authentication handshake).
So, if there is an authentication context and IE cannot determine the SERVER type or determines a Server type of IIS v1.0/2.0/30 and the response is not a 401 server response, the port is gracefully closed (a FIN ACK instead of a RST).
So the reason behind the behavior is now understood. Unfortunately, the behavior has been in the product so long, the history behind it is not (sorry folks).
Regards,
The IE Support Team