From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43165) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bD8AB-0004CO-Uk for qemu-devel@nongnu.org; Wed, 15 Jun 2016 06:35:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bD8AA-0004q9-SV for qemu-devel@nongnu.org; Wed, 15 Jun 2016 06:35:11 -0400 References: <1463006384-7734-1-git-send-email-eblake@redhat.com> <575EA656.80508@redhat.com> <6DD06745-C91C-4BFB-BFE5-92E5982ACB42@alex.org.uk> <11f620d2-a51d-5235-5abd-4ced314c9090@redhat.com> <38ABE56B-CA23-4372-A413-CDA72BDAE86A@alex.org.uk> <20160615070522.GC3787@grep.be> <20160615080346.GA6994@grep.be> <077010D7-81BE-4AD5-B36A-408844852006@alex.org.uk> <2050439854.22663791.1465982331939.JavaMail.zimbra@redhat.com> <2974A238-B81A-4D02-9FB6-7A70C0AA6E8F@alex.org.uk> From: Paolo Bonzini Message-ID: <703d4836-e250-857b-cb3e-a6e0c3f02f5a@redhat.com> Date: Wed, 15 Jun 2016 12:34:59 +0200 MIME-Version: 1.0 In-Reply-To: <2974A238-B81A-4D02-9FB6-7A70C0AA6E8F@alex.org.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [Nbd] [PATCH v4 04/11] nbd: Improve server handling of bogus commands List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Bligh Cc: Wouter Verhelst , "nbd-general@lists.sourceforge.net" , "qemu-devel@nongnu.org" , qemu block On 15/06/2016 12:27, Alex Bligh wrote: >=20 > On 15 Jun 2016, at 10:18, Paolo Bonzini wrote: >=20 >>> So what should those servers do (like 2 of mine) which don't buffer >>> the entire read, if they get an error having already sent some data? >> >> They have sent an error code of zero, and it turned out to be wrong. = So >> the only thing they can do safely is disconnect. >=20 > Right, but that is not what Wouter's change says: >=20 > + If an error occurs, the server SHOULD set the appropriate error co= de > + in the error field. The server MAY then initiate a hard disconnect= . > + If it chooses not to, it MUST NOT send any payload for this reques= t. >=20 > I read this as either >=20 > a) the server can issue a hard disconnect without sending any reply; or >=20 > b) it must send the reply header with no payload >=20 > It also seems to permit not setting the error code (it's only a 'SHOULD= '), > not disconnecting (it's a MAY), then not sending any payload, which is = a > nonsense. Right. > Perhaps this should read "If an error occurs, the server MUST either in= itiate > a hard disconnect before the entire payload has been sent or > set the appropriate code in the error field and send the response heade= r > without any payload." if we want to go down this route. Yes, I agree. I do believe we want to go down this route. I think we agree that partial buffering may always require the server to disconnect after an error. Therefore I don't see any benefit at all in sending a payload after an error message. Paolo