- From: John Franks <john@math.nwu.edu>
- Date: Sat, 17 Dec 1994 08:44:13 -0600 (CST)
- 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 UTC