From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.142.140.7 with SMTP id n7cs3805wfd; Wed, 11 Nov 2009 15:00:58 -0800 (PST) Return-Path: Received-SPF: pass (google.com: domain of grbounce-ceibQwUAAAB4YPBqaDIjI2bFOCxyyh3G=chneukirchen=gmail.com@googlegroups.com designates 10.100.24.22 as permitted sender) client-ip=10.100.24.22; Authentication-Results: mr.google.com; spf=pass (google.com: domain of grbounce-ceibQwUAAAB4YPBqaDIjI2bFOCxyyh3G=chneukirchen=gmail.com@googlegroups.com designates 10.100.24.22 as permitted sender) smtp.mail=grbounce-ceibQwUAAAB4YPBqaDIjI2bFOCxyyh3G=chneukirchen=gmail.com@googlegroups.com; dkim=pass header.i=grbounce-ceibQwUAAAB4YPBqaDIjI2bFOCxyyh3G=chneukirchen=gmail.com@googlegroups.com Received: from mr.google.com ([10.100.24.22]) by 10.100.24.22 with SMTP id 22mr2591332anx.26.1257980457549 (num_hops = 1); Wed, 11 Nov 2009 15:00:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=beta; h=domainkey-signature:received:received:x-sender:x-apparently-to :mime-version:content-type:content-transfer-encoding:received:date :in-reply-to:x-ip:references:user-agent:x-http-useragent:message-id :subject:from:to:x-google-approved:reply-to:sender:precedence :x-google-loop:mailing-list:list-id:list-post:list-help :list-unsubscribe:x-beenthere-env:x-beenthere; bh=/1ObvBk1hCqwCAauVuKdv8CpFOP9smdX4XfTRUHVLew=; b=dZNDyHmRiZuXSQpIeR5A3RXJ6oehf7oJfSKvBW14PURlenkgwhO2ZzMnpz0VAm/tgw UmvX8j11BDBjy60C8iQMiYWVLUwZ1fCen8u5EOAQhvoI7y3hgJ+K3ZCGoeKeV9nMnS7c 11byitpwOGVvXZnz2Cj6SImCKoNTh5CmcGlpw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlegroups.com; s=beta; h=x-sender:x-apparently-to:mime-version:content-type :content-transfer-encoding:date:in-reply-to:x-ip:references :user-agent:x-http-useragent:message-id:subject:from:to :x-google-approved:reply-to:sender:precedence:x-google-loop :mailing-list:list-id:list-post:list-help:list-unsubscribe :x-beenthere-env:x-beenthere; b=Thj2192U+HmlBfKAL32gB/cOb/io4ePBZwtUa/1nJy0yxi+fQr5c0lZtZpRZxwYh5q GlCI5PNDuSU/kzDe/XZVLlIR3ICto4T6bXwPA73QSCn4RvjsIcQSxFBNlow2ly0FsAiC OU64FLQMBTELZ1hj88thlTkjRCEzlLoI52BV0= Received: by 10.100.24.22 with SMTP id 22mr212851anx.26.1257980457490; Wed, 11 Nov 2009 15:00:57 -0800 (PST) Received: by 10.176.233.14 with SMTP id f14gr1719yqh.0; Wed, 11 Nov 2009 15:00:48 -0800 (PST) X-Sender: bosko.milekic@gmail.com X-Apparently-To: rack-devel@googlegroups.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Received: by 10.101.131.20 with SMTP id i20mr198102ann.35.1257972832307; Wed, 11 Nov 2009 12:53:52 -0800 (PST) Date: Wed, 11 Nov 2009 12:53:52 -0800 (PST) In-Reply-To: X-IP: 74.57.49.115 References: User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-us) AppleWebKit/531.9 (KHTML, like Gecko) Version/4.0.3 Safari/531.9,gzip(gfe),gzip(gfe) Message-ID: Subject: Re: RQFR: multipart bug From: Bosko Milekic To: Rack Development X-Google-Approved: m.fellinger@gmail.com via web at 2009-11-11 23:00:48 Reply-To: rack-devel@googlegroups.com Sender: rack-devel@googlegroups.com Precedence: bulk X-Google-Loop: groups Mailing-List: list rack-devel@googlegroups.com; contact rack-devel+owner@googlegroups.com List-Id: List-Post: List-Help: List-Unsubscribe: , X-BeenThere-Env: rack-devel@googlegroups.com X-BeenThere: rack-devel@googlegroups.com On Nov 6, 1:01=A0pm, Christian Neukirchen wrote: > > Introduce failing test case for multipart parser when it slices > > exactly on a boundary and patch multipart parser so it passes it - > > the failing test case comes with a sample payload specific to the > > fact that the default bufsize used by the multipart parser is > > exactly 16384. =A0should this default be changed, the test will no > > longer apply. > > http://github.com/bloom/rack/commit/8f4bfced74e7a07d0f0f47705b763c7ef... Obviously I'll +1 here, but I'm clearly biased. :-) In all honesty, though, I think the "correct" thing to do is rewrite the multi-parser method, which is really non obvious and not exactly what one would call idiomatic ruby, but since this is much easier said than done, I'm all for patching the edge case. Took a while to isolate this, especially since only Safari was sending payloads that happened to, in very specific and isolated cases, fall exactly on the end of the boundary at the 16384 byte offset. Best, Bosko