From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Thompson, David" Subject: Re: [PATCH] Add MARS shooter. Date: Sat, 19 Sep 2015 16:33:02 -0400 Message-ID: References: <8761377ct3.fsf@elephly.net> <871tdu7r3f.fsf@elephly.net> <87twqq5g3o.fsf@elephly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:48941) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZdOok-0005sJ-Fu for guix-devel@gnu.org; Sat, 19 Sep 2015 16:33:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZdOoh-0002Yg-AD for guix-devel@gnu.org; Sat, 19 Sep 2015 16:33:06 -0400 Received: from mail-yk0-f177.google.com ([209.85.160.177]:33683) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZdOoh-0002Yc-6L for guix-devel@gnu.org; Sat, 19 Sep 2015 16:33:03 -0400 Received: by ykft14 with SMTP id t14so74031695ykf.0 for ; Sat, 19 Sep 2015 13:33:02 -0700 (PDT) In-Reply-To: <87twqq5g3o.fsf@elephly.net> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Ricardo Wurmus Cc: guix-devel On Sat, Sep 19, 2015 at 4:06 PM, Ricardo Wurmus wrote: > > Thompson, David writes: > >>> =E2=80=9CContent-Type: .gz=E2=80=9D is what trips up =E2=80=9Cguix down= load=E2=80=9D. What follows >>> =E2=80=9CContent-Type:=E2=80=9D should be a mime type and I suppose =E2= =80=9C.gz=E2=80=9D is not a valid >>> mime type. Would it make sense for the HTTP client to be a little more >>> tolerant about this? >> >> No, upstream needs to fix their invalid Content-Type header. We've >> had this problem a few times, most recently with rubygems.org, and in >> all cases we've gotten upstream to fix it. Strict header parsing can >> seem like an issue at times, but it's really a very good feature that >> the rest of the world seems to ignore. [0] > > I wonder what a correct Content-Type header would look like in this > case. I would like to submit a helpful report containing what I got and > what it should have been. In this case, application/x-gzip or application/octet-stream would be appropriate. Less specifically, the media type needs to match the syntax as defined by the W3C spec. [0] > However, this is independent from the patch itself where I=E2=80=99m usin= g a git > reference. Ah yes, you are right. :) - Dave [0] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7