From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59300) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UkrNm-0004jb-7Z for qemu-devel@nongnu.org; Fri, 07 Jun 2013 03:46:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UkrNj-0006cJ-3S for qemu-devel@nongnu.org; Fri, 07 Jun 2013 03:46:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55544) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UkrNi-0006c5-Rx for qemu-devel@nongnu.org; Fri, 07 Jun 2013 03:46:43 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r577kgKa013096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 7 Jun 2013 03:46:42 -0400 Date: Fri, 7 Jun 2013 09:46:40 +0200 From: Stefan Hajnoczi Message-ID: <20130607074640.GE16953@stefanha-thinkpad.redhat.com> References: <1370499959-8916-1-git-send-email-famz@redhat.com> <20130606110157.GM4515@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130606110157.GM4515@redhat.com> Subject: Re: [Qemu-devel] [PATCH v7 00/13] curl: fix curl read List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Richard W.M. Jones" Cc: kwolf@redhat.com, jcody@redhat.com, Fam Zheng , qemu-devel@nongnu.org On Thu, Jun 06, 2013 at 12:01:57PM +0100, Richard W.M. Jones wrote: > On Thu, Jun 06, 2013 at 02:25:46PM +0800, Fam Zheng wrote: > > v7: > > 13: Added: > > curl: change timeout to 30 seconds > > I tested this against: > > (1) HTTP to Apache server over slow but local wifi. > > (2) HTTP to a remote ISO (on another continent). > > Test (1) is fine. > > Test (2) gives plenty of I/O errors. I guess that 30 seconds isn't > sufficient here. > > I should note that current upstream qemu *works* in both cases. > Although the timeout in current qemu is much shorter (5 seconds), for > some reason this does not affect the test. > > I'm also confused about what problem this patch series is trying to > fix, since upstream qemu works fine for me with the latest curl. One problem I've had with the upstream code is that HTTP servers which do not support Range: headers fail in a weird way (I don't remember exactly what happens). This series does improve this by explicitly checking for Range: header support. But there is a lot of other refactoring going on which is reasonable only if it works as well or better than the upstream code. Stefan