W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1994

Re: Connection Header

From: John Franks <john@math.nwu.edu>
Date: Sat, 17 Dec 1994 08:44:13 -0600 (CST)
Message-Id: <9412171444.AA00770@hopf.math.nwu.edu>
To: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
According to Roy T. Fielding:
> 
>    For example, an experimental client may send:
> 
>       Connection: keep-alive
> 
>    to indicate that it desires to keep the connection open for multiple
>    requests. The server may then respond with a message containing:
> 
>       Connection: keep-alive, timeout=10, maxreq=5
>    
>    to indicate that the connection will be kept open for a maximum of 5
>    requests, but will timeout if the next request is not received within
>    10 seconds. 
>
...
> 
> Comments, please?
> 

I have some some serious reservations about this.  Perhaps someone
more knowledgeable about TCP/IP can alleviate them.  Won't this
maintain the connection during the entire time that a client takes to
download and layout and display a document containing containing
mulitple images?  This could represent a substantial amount of time
over a slow link.  For a heavily loaded server, say like HotWired,
keeping the connection open during the entire time a user enters her
password and multiple images in a document are downloaded over a 14.4
link could add up to quite a bit of time.  I would think that the
maximum number of allowed connections would be exceded quite often.
There would probably be a large number of timeouts each one representing
almost 10 seconds of unused connect time.

By contrast, I would think that an MGET connection sending the same
data could be a relatively short transaction for the server.  Am I
wrong about this?  Of course, MGET would require two connections --
one GET for the HTML doc and image size headers and a second MGET for
all the images.  But the difference between these two would be
neglible for the client and potentially a very significant win for the
server.

I don't see that MGET poses any problems for proxies.  They would have
to parse the MGET and decide which files they have cached and which
they need to fetch.  Old (HTTP1.0) servers and proxies would send an
unknown method message when they get an MGET and the client would then
re-issue a sequence of GETs. 

> 
> ......Roy Fielding   ICS Grad Student, University of California, Irvine  USA
>                                      <fielding@ics.uci.edu>
>                      <URL:http://www.ics.uci.edu/dir/grad/Software/fielding>
> 
Received on Saturday, 17 December 1994 06:45:02 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:09 EDT