From owner-freebsd-current Thu Jul 24 17:01:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA03386 for current-outgoing; Thu, 24 Jul 1997 17:01:31 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA03378 for ; Thu, 24 Jul 1997 17:01:27 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.8.5/8.8.5) id UAA13578; Thu, 24 Jul 1997 20:01:19 -0400 (EDT) Date: Thu, 24 Jul 1997 20:01:19 -0400 (EDT) From: Garrett Wollman Message-Id: <199707250001.UAA13578@khavrinen.lcs.mit.edu> To: Bill Fenner Cc: Garrett Wollman , =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= , current@freebsd.org Subject: Re: 'fetch' error with http, fix wanted In-Reply-To: <97Jul24.163153pdt.177512@crevenia.parc.xerox.com> References: <199707241422.KAA29714@khavrinen.lcs.mit.edu> <97Jul24.163153pdt.177512@crevenia.parc.xerox.com> Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk < said: > want to try to detect clients that have disappeared, and there's a > common (T/TCP-breaking) assumption that if you get a read EOF then > the connection is gone and you should tear it down at the application > level. Not just Transaction TCP.... That's a pretty clear failure on their part in terms of the TCP spec as a whole. There's nothing preventing any Web browser from doing a shutdown() on the socket after it transmits its request. (Of course, a lot of TCPs don't do anything on shutdown(), but that's another story altogether.) -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick