From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53480) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bzKLB-0008DX-QL for qemu-devel@nongnu.org; Wed, 26 Oct 2016 05:17:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bzKLA-0005nT-TP for qemu-devel@nongnu.org; Wed, 26 Oct 2016 05:17:45 -0400 Date: Wed, 26 Oct 2016 11:17:37 +0200 From: Kevin Wolf Message-ID: <20161026091737.GH4758@noname.str.redhat.com> References: <20161025025431.24714-1-mreitz@redhat.com> <20161025025431.24714-3-mreitz@redhat.com> <998633c9-ab39-0674-c25c-5c1b185b99e7@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TYecfFk8j8mZq+dy" Content-Disposition: inline In-Reply-To: <998633c9-ab39-0674-c25c-5c1b185b99e7@redhat.com> Subject: Re: [Qemu-devel] [PATCH 2/4] block/curl: Fix return value from curl_read_cb List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Max Reitz , qemu-block@nongnu.org, Jeff Cody , qemu-stable@nongnu.org, qemu-devel@nongnu.org, mbooth@redhat.com, rjones@redhat.com --TYecfFk8j8mZq+dy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 25.10.2016 um 20:37 hat Eric Blake geschrieben: > On 10/24/2016 09:54 PM, Max Reitz wrote: > > While commit 38bbc0a580f9f10570b1d1b5d3e92f0e6feb2970 is correct in that > > the callback is supposed to return the number of bytes handled; what it > > does not mention is that libcurl will throw an error if the callback did > > not "handle" all of the data passed to it. > >=20 > > Therefore, if the callback receives some data that it cannot handle > > (either because the receive buffer has not been set up yet or because it > > would not fit into the receive buffer) and we have to ignore it, we > > still have to report that the data has been handled. > >=20 > > Obviously, this should not happen normally. But it does happen at least > > for FTP connections where some data (that we do not expect) may be > > generated when the connection is established. >=20 > Just to make sure, we aren't losing data by reporting this value, but > merely letting curl know that our callback has "dealt" with the data, so > that we don't error out, in order to get a second chance at the same > data later on? >=20 > Reviewed-by: Eric Blake >=20 > But given that it undoes 38bbc0a, I'd rather that it gets reviewed by > Matthew and/or tested by Richard. In that case, I guess we should CC them. (Hereby done.) Kevin --TYecfFk8j8mZq+dy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJYEHSxAAoJEH8JsnLIjy/WTa8P/2Cn3ywkgnedTnsLo6qOtWIQ oxmT8JLIaSaTQffuimtd/BTBwDuCgVrC+DN10i6rrKUoi10GRMLUYEucHRYLEdJ4 fGBx6VqK86yeEDxAAcHvWmKjw84xzuNRRcNSfBSWapbT3RMYpKvLoLWru3uuEpot Fh2R41s8YEeMRSgCmZcINwX1Y9Lr0FKdOE14D/c8Q7vSDbSgDcMTmXApGPc9cDH3 HQBUQu6Yr1pVzRrhOWB6PezcOmPTozFqv7ieSMKeKcJ2kM0UZ74G1Vg6FV2u0GV4 LvJy8LtkWxFXhEd63uSAN9WDN+KjOYzomGfn5v4J9Q5z1UPLw9CRUweBXzE37zck PzPRCuC/kO5LeJ3vixIXpp4/P0X7DkkJY0X1mv8F+yj8aQ3yhtwbLZ/GS5UfpgAk w8Ke2NVCXAVJSu+N+s9/8th4pHI1GRpXdMcQxF3KbIyjpZ6DB6SS8uSk7xV2LTde YSxWWEKqUKnGx6meWmqIbqMyUt74E5S/bR9T3HybDpdRzr1QzY1J7KsFk7u/lNbf KotiwEdQ2TjtTibsBWly/OkBILr/1q6OZxEnoSAgMuN8fEkgl+OxSxYKj2Mx6X6/ DrrCyJvu/o3+FE6Ougt294LJ+6Sbjj1cY9hfWAX+HP5nANUSOm87oyRDo0BncoG6 ZbP0+kcHUXZuyQ+MzXYF =yzq8 -----END PGP SIGNATURE----- --TYecfFk8j8mZq+dy--