From owner-freebsd-net@FreeBSD.ORG Fri Jul 20 23:06:04 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48D3616A418 for ; Fri, 20 Jul 2007 23:06:04 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outW.internet-mail-service.net (outW.internet-mail-service.net [216.240.47.246]) by mx1.freebsd.org (Postfix) with ESMTP id 28DF113C474 for ; Fri, 20 Jul 2007 23:06:03 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 20 Jul 2007 16:06:03 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 1386B125A2A; Fri, 20 Jul 2007 16:06:03 -0700 (PDT) Message-ID: <46A13FF5.9070806@elischer.org> Date: Fri, 20 Jul 2007 16:06:29 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: karels@karels.net References: <200707202239.l6KMdSq4035780@redrock.karels.net> In-Reply-To: <200707202239.l6KMdSq4035780@redrock.karels.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Julian Elischer , FreeBSD Net Subject: Re: Wierd networking. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 23:06:04 -0000 Mike Karels wrote: >> I think that the possible courses of action are: > >> 1/ Ignore further incoming data, but ACK it. >> (this is basically what the userland code does in this case) > > This could lead to indefinite data transfer, while misleading the sender > into thinking the data are being delivered. > >> 2/ Stop ACKing the data, and let the other end time out. > > This seems like a waste of resources on both ends of the connection; > both are doomed, but they both have to time out to go away. > >> 3/ Send a RST > > This is my choice, literally: I added the code to send a RST in this > case sometime in the 1980s, after observing connections that hung > with no reader, but with the writer in persist mode indefinitely. > (That's choice 4: accept the data, let the receive buffer fill, then > advertise a zero window forever.) > > Mike 5/ throw away SOME data and then resort to RST. the problem we ahve is that IE7 seems to send some data after the FIN is sent by the server, and complains when it gets the RST.\ The exact problem is when the FIN is because of a redirection (due to a 407, (proxy auth required), and IE aborts the whole transfer.. so: IE: "POST (or GET) bla bla" proxy: "407 (proxy auth required)"... FIN IE: "CR/LF" proxy: "RST" IE: [displays erro screen and fails to continue] We have changed the proxy to do a shutdown and keep receiving (and discarding) the data until it gets an EOF but I worry about DOS possibilities.. I think I may add code to make this only accept some limited amount of data before doing the close().