From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60454) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UkrUA-0008GH-T2 for qemu-devel@nongnu.org; Fri, 07 Jun 2013 03:53:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UkrU8-0000e9-16 for qemu-devel@nongnu.org; Fri, 07 Jun 2013 03:53:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44795) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UkrU7-0000e1-OB for qemu-devel@nongnu.org; Fri, 07 Jun 2013 03:53:19 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r577rILU016054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 7 Jun 2013 03:53:19 -0400 Date: Fri, 7 Jun 2013 15:53:19 +0800 From: Fam Zheng Message-ID: <20130607075319.GB26941@localhost.nay.redhat.com> References: <1370499959-8916-1-git-send-email-famz@redhat.com> <20130606110157.GM4515@redhat.com> <20130607074640.GE16953@stefanha-thinkpad.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130607074640.GE16953@stefanha-thinkpad.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: Stefan Hajnoczi Cc: kwolf@redhat.com, jcody@redhat.com, "Richard W.M. Jones" , qemu-devel@nongnu.org On Fri, 06/07 09:46, Stefan Hajnoczi wrote: > 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. > What I see is it always returns the first sectors to guest. > 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. > In this case it doesn't :( I can probably send a fix for range and drop the refactoring for now. -- Fam