W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 1995

Re: NCSA implementation of KeepAlive

From: Dave Kristol <dmk@allegra.att.com>
Date: Fri, 20 Oct 95 09:35:03 EDT
Message-Id: <199510201342.AA052146524@hplb.hpl.hp.com>
To: efrank@ncsa.uiuc.edu
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
efrank@ncsa.uiuc.edu (Beth Frank) wrote:
  > In response to some of the questions that were sent early
  > last week...
  > "timeout" is idle time.
  > We decided that the server needed to set a maximum number of
  > requests and a maximum idle time on the connection to prevent
  > a client from "hogging the server" and protect against denial
  > of service request.  The client folks thought it could be useful
  > to have the information on the limits, so we send it.  I'm not
  > sure whether they change their behavior based on the values or
  > not.  To get around some Mac TCP/IP peculiarities, we did work
  > out that each additional request from the client had to include
  > the "Connection: Keep-Alive" header or the server will assume
  > it is the last request and close connection after serving the
  > request.  

I would like the client folks to tell us what they actually do with the
information the server returns.  I agree it's important to prevent a
client from hogging a server, but that's easily accomplished:

1) The server can always, as a last resort, break the connection.
2) The server can fail to return a Connection: Keep-alive response header,
and the client will (should) know that the connection will close.

So the number-of-connections information in the Keepalive response
header is redundant.  And I've also previously stated my skepticism
about the worth of the idle-time piece of Keepalive.

(Oh, and Roy, I failed to rise to your bait about other aspects of your
description of Keep-alive in the spec. because I've been real busy, and
I probably don't understand the issues well enough to be upset. :-)

Dave Kristol
Received on Friday, 20 October 1995 06:46:02 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:42:56 UTC