I'm using a Common Gateway Interface (CGI) application on IIS 5.0, and I've noticed that IIS ends the TCP session after each exchange. The client browsers are HTTP 1.1 compliant, and I've enabled Keep Alive. What's causing IIS to send Connection:Closed in the HTTP headers even though the browser requests Connection:Keep-Alive?
A bit of history will get you to the answer. HTTP isn't a static protocol standard, and new features are added all the time. The original protocol was designed to be stateless, and IIS closed the client's TCP connection at the end of every transmission. Contrary to popular belief, HTTP 1.0 could keep a TCP connection open but in every exchange, both the client and the server had to request that the session stay open. In HTTP 1.1, Keep-Alive connections are the standard, so the connection remains open unless explicitly closed. If you've looked at the packets from HTTP sessions recently, you've probably noticed that the Keep-Alive headers are, in effect, no longer necessary.
For successful Keep-Alive implementation, the client and server must negotiate a way to communicate how much information is being transferred. Internet Engineering Task Force (IETF) Request for Comments (RFC) 2616 (http://www.w3.org/pro tocols/rfc2616/rfc2616-sec8.html #sec8) requires this negotiation for a persistent HTTP session. Section 8.1.2.1 states that
In order to remain persistent, all messages on the connection MUST have a self-defined message length (i.e., one not defined by closure of the connection), as described in section 4.4.
In HTTP 1.1 and HTTP 1.0, this persistent session is achieved through the Content-Length HTTP header. Using the Content-Length header, the server can inform the browser exactly how much information the body of the transmission contains. However, what if you're running a Web application and the server doesn't know exactly how much information it's sending to the client? To permit a Keep-Alive connection in this scenario, HTTP 1.1 included a chunked transfer encoding feature. (For more information about chunked transfer encoding, see Section 3.6 of IETF RFC 2068 at http://www.w3.org/ protocols/rfc2068/ rfc2068.) Using this method, IIS breaks up a transmission into a larger transmission in discreet chunks, each chunk with a unique Content-Length header.
An interesting aspect of chunked encoding is that the client can also use this technique to send information to the server. In IIS 4.0, such a request causes IIS to allocate memory for the expected upload. In fact, if the client sends repeated requests to IIS 4.0 for such a transfer but never sends the information, the requests can effectively shut IIS 4.0 down while the session that's making the requests is alive. For information about this special malformed header attack, see the Microsoft article "Chunked Encoding Request with No Data Causes IIS Memory Leak" (http://support.microsoft.com/support/kb/articles/q252/6/93.asp). To download the fix for this bug, go to http://download.microsoft.com/download/iis40/patch/4.2.739.1/ nt4/en-us/chkenc4i.exe. (No Windows NT service packs include this fix.)
So, to answer the question, you know that to support Keep-Alive headers, IIS must send the content length. Thus, you must look at the various methods that IIS can use to deliver content and how those methods relate to using Keep-Alive headers.
IIS can send static content or dynamic content by using Active Server Pages (ASP), Internet Server API (ISAPI), or CGI files. IIS can easily keep a static content session alive because the file length is known and fixed. A scripting engine such as ASP uses Keep-Alive headers by calculating the length of the content and sending the known content length to the server. The server then uses chunked encoding, if necessary. ASP can use Keep-Alive headers only if you've enabled buffering (the default in IIS 5.0) and you don't flush the buffer. (For more information about ASP and Keep-Alive headers, see the Microsoft article "HTTP Keep-Alive Header Sent Whenever ASP Buffering is Enabled," http://support.microsoft.com/sup port/kb/articles/q238/2/10.asp.)
IIS ISAPI applications can also use Keep-Alive technology, including chunked transfer encoding. (For more information about ISAPI and Keep-Alive headers, see the Microsoft article "Chunked Transfer Encoding," http://msdn.microsoft.com/library/default.asp?url=/library/en-us/iisref/html/ psdk/asp/devs1pev.asp.) However, you must specifically develop the application to employ these techniques; otherwise, IIS must close the connection after a transfer.
CGI applications in IIS 5.0 and IIS 4.0 can't use the Keep-Alive features of HTTP 1.1, no matter what the applications do. For this reason, you'll see that IIS sends the Connection:Closed HTTP header even though the browser indicates that it wants a Keep-Alive connection and you've enabled Keep-Alive headers in IIS.
| FOR MORE INFORMATION |
|
Understanding Microsoft Internet Explorer (IE) security zones is crucial for setting permissions-based security in IIS. Here
are a few resources to get you started. (http://www.nwnetworks.com/iezones.htm) (http://support.microsoft.com/support/kb/articles/q258/0/63.asp) (http://www.microsoft.com/technet/prodtechnol/ie/reskit/ie5/part1/ch07zone.asp) |
