IIS HTTP 1.1 keep-alive potential issue

Hello,

I was wondering if anyone had ever come across an issue with HTTP 1.1
keep-alives not functioning properly in IIS, although it is configured
to use them, and the client requests them.

We have several web applications in our environment exhibiting similar
behavior.

Client sends an HTTP request with connection: keep-alive in the header.


Server responds to this request, but does not indicate either
connection: keep-alive OR connection: close. The client (IE) is
configured to use HTTP 1.1 by default, and IIS is configured to use
keep-alives.

The resulting behavior is similar to 1.0, where the client opens up a
TCP connection for each object on the page.

I've seen some interesting articles with similar symptoms, but most of
them were related to CGI. Those articles also indicated that the
server would respond with a connection: closed, which is not happening
in my case.

I'm not too sure what the code is running on the web servers, but I
know in one case, it's Siebel, if that helps.

Thanks in advance,
Kristin

Unfortunately, I need to ask you to better define what "HTTP 1.1 keep-alives
not functioning" means. Here's why.

What you have to realize is that connection keep-alive is not something a
client can simply ask for and get 100% of the time. Remember that
keep-alive is a TCP-level optimization behavior that the webserver, at the
HTTP level, really doesn't care a whole lot about (other than obeying simple
HTTP semantics called out in the spec).

There are A LOT of interactions between the client, server, and server-side
application that have to be perfectly in-sync in order for HTTP Keep-Alive
to be negotiated and used, including:
1. Client *must* support and ask for keep alive. This means either HTTP 1.0
with Connection: Keep-Alive header or HTTP 1.1 without Connection: Close
header, and it must keep the connection open.
2. Server *must* allow keep-alive. This means that the W3SVC/AllowKeepAlive
property must be set to TRUE (it defaults to TRUE, so you should never have
to set it unless you've changed it from the default)
3. The Server-Side application must allow keep-alive. With an ISAPI-based
application, there are many choices, but it basically comes down to the
server-side application telling IIS "I'm ok with keep-alive" though various
means). And the application must also not tell the server to close the
connection.

Along with many other factors (including any other ISAPI Filters/Extensions
on the server, whose behaviors are totally unknown from your perspective),
these things determine whether a given request over a connection is
keep-alive or not.

Since you've barely given any information about these factors about
keep-alive, it is nearly impossible to figure out whether there is a real
issue with IIS (what IIS version are we talking about?), or that something
else on the server is causing the issue, or whether you simply did not
configure the server to behave the way you want.

Also, it is not clear to me:
1. how you are determining that the client is opening up a new connection
for each object on the page
2. how you configured IIS to use keep-alive (you can only configure IIS to
*not* use keep-alive -- you cannot configure IIS to use/force keep-alive)
3. how you determined that your web applications are even cooperating and
compatible with keep-alive. Remember, keep-alive is the newer TCP behavior,
so using it incorrectly can cause web browser to hang while not using it is
always safe.
4. If #1 is true, who actually closeod the connection -- client or server?
If Client closes the connection for some reason, server will oblige.
Keep-alive is not a contract -- it is negotiated compatibility between
client and server and both sides can break it at anytime.

Basically, to look at connection keep-alive issues, you must provide Network
Monitor (or comparable) traces (both HTTP and TCP level) of the
request/responses in question, and you must provide full configuration of
code (ISAPI Filter/Extensions) running on the server that is involved with
those requests. Until you enumerate/eliminate each piece from touching the
request, there is really insufficient evidence to start a "IIS HTTP 1.1
keep-alive potential issue" thread saying IIS is not functioning properly.
There are dozens of moving pieces involved, of which IIS is only involved in
a couple... so unfortunately, keep-alive is not as simple as you think.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Kristin" <kristin1 DeleteThis @gmail.com> wrote in message
news:1108262594.552140.179270@c13g2000cwb.googlegroups.com...
Hello,

I was wondering if anyone had ever come across an issue with HTTP 1.1
keep-alives not functioning properly in IIS, although it is configured
to use them, and the client requests them.

We have several web applications in our environment exhibiting similar
behavior.

Client sends an HTTP request with connection: keep-alive in the header.


Server responds to this request, but does not indicate either
connection: keep-alive OR connection: close. The client (IE) is
configured to use HTTP 1.1 by default, and IIS is configured to use
keep-alives.

The resulting behavior is similar to 1.0, where the client opens up a
TCP connection for each object on the page.

I've seen some interesting articles with similar symptoms, but most of
them were related to CGI. Those articles also indicated that the
server would respond with a connection: closed, which is not happening
in my case.

I'm not too sure what the code is running on the web servers, but I
know in one case, it's Siebel, if that helps.

Thanks in advance,
Kristin