From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.239.138.72 with SMTP id o8cs151507hbo; Tue, 6 Jul 2010 00:54:23 -0700 (PDT) Return-Path: Received-SPF: pass (google.com: domain of rack-devel+bncCI7buMj8DBCtwsvhBBoE7p5lvw@googlegroups.com designates 10.229.1.99 as permitted sender) client-ip=10.229.1.99; Authentication-Results: mr.google.com; spf=pass (google.com: domain of rack-devel+bncCI7buMj8DBCtwsvhBBoE7p5lvw@googlegroups.com designates 10.229.1.99 as permitted sender) smtp.mail=rack-devel+bncCI7buMj8DBCtwsvhBBoE7p5lvw@googlegroups.com; dkim=pass header.i=rack-devel+bncCI7buMj8DBCtwsvhBBoE7p5lvw@googlegroups.com Received: from mr.google.com ([10.229.1.99]) by 10.229.1.99 with SMTP id 35mr2927905qce.15.1278402862324 (num_hops = 1); Tue, 06 Jul 2010 00:54:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=beta; h=domainkey-signature:received:x-beenthere:received:received:received :received:received-spf:received:mime-version:received:received :in-reply-to:references:date:message-id:subject:from:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :sender:list-subscribe:list-unsubscribe:content-type :content-transfer-encoding; bh=3loym7zSHCrRKm9tkfcuD/81j0DARO+0a7ptZ+as1m8=; b=j/xGAmPzeo3V9hUihN/dWfOvrIToWnYFttiWAeFXRAAxAHNGevqgnPSxJSReg7JWU+ sE4ssiFPTfkLAqEF/9F7BcCU1tXU5LVfmixtO2N+vw4q/RFXO4FnpNAovr6jnI5QPPkp TJbGgHYsL02zXTU9k7th6oWWej/OH1EQISbbI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlegroups.com; s=beta; h=x-beenthere:received-spf:mime-version:in-reply-to:references:date :message-id:subject:from:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:sender:list-subscribe :list-unsubscribe:content-type:content-transfer-encoding; b=Wjg0pg/7PGUIIbjMPGfc9opTjcDwLvKNzWjauBBfwCh3Vkuk5zbr1PgE9zbrui//f2 RFsxJ6Evuoawf/r3qAQuUfle+hiAbUjctm9tpGpmEaqOCNKWBvYlqertIi4KmzTNo7nV nzztOj1q4YXUTrZp1JH/C+kNHZwER8kRqejj0= Received: by 10.229.1.99 with SMTP id 35mr466055qce.15.1278402861218; Tue, 06 Jul 2010 00:54:21 -0700 (PDT) X-BeenThere: rack-devel@googlegroups.com Received: by 10.229.179.165 with SMTP id bq37ls3340025qcb.3.p; Tue, 06 Jul 2010 00:54:20 -0700 (PDT) Received: by 10.229.221.72 with SMTP id ib8mr328914qcb.0.1278402860285; Tue, 06 Jul 2010 00:54:20 -0700 (PDT) Received: by 10.229.221.72 with SMTP id ib8mr328913qcb.0.1278402860243; Tue, 06 Jul 2010 00:54:20 -0700 (PDT) Received: from mail-vw0-f53.google.com (mail-vw0-f53.google.com [209.85.212.53]) by gmr-mx.google.com with ESMTP id f13si3049257qcq.5.2010.07.06.00.54.20; Tue, 06 Jul 2010 00:54:20 -0700 (PDT) Received-SPF: neutral (google.com: 209.85.212.53 is neither permitted nor denied by best guess record for domain of jeremy@bitsweat.net) client-ip=209.85.212.53; Received: by vws15 with SMTP id 15so8098363vws.12 for ; Tue, 06 Jul 2010 00:54:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.230.131 with SMTP id jm3mr2370641qcb.124.1278402859685; Tue, 06 Jul 2010 00:54:19 -0700 (PDT) Received: by 10.229.47.9 with HTTP; Tue, 6 Jul 2010 00:54:19 -0700 (PDT) In-Reply-To: References: Date: Tue, 6 Jul 2010 00:54:19 -0700 Message-ID: Subject: Re: Consider reverting multipart parsing change From: Jeremy Kemper To: rack-devel@googlegroups.com X-Original-Sender: jeremy@bitsweat.net X-Original-Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 209.85.212.53 is neither permitted nor denied by best guess record for domain of jeremy@bitsweat.net) smtp.mail=jeremy@bitsweat.net Reply-To: rack-devel@googlegroups.com Precedence: list Mailing-list: list rack-devel@googlegroups.com; contact rack-devel+owners@googlegroups.com List-ID: List-Post: , List-Help: , List-Archive: Sender: rack-devel@googlegroups.com List-Subscribe: , List-Unsubscribe: , Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jul 5, 2010 at 3:57 PM, Mark Goris wrote: > It's been a long time since I created the initial ticket, so I've lost > some of the context (especially in the subsequent discussion that led > to this change that you've suggested to revert). =A0It seemed best to me > that tempfiles only be used in the case of having a filename attribute > be present, regardless of content-type. =A0Your suggestion seems to > focus on the specific type of content-type driving logic regarding > whether or not a part is treated as a file upload. =A0I guess my > question is, why not just use the filename attribute to drive this > logic? =A0I don't know of a downside to this approach (meaning, I'm not > exactly clear on the intention for the change that prompted ticket 79 > in the first place). Checking for filename works for file uploads from web browsers. All other MIME parts are flattened to a "normal" form parameter even it it was neither a form param or a file upload. For example, see the multipart/mixed regression on #79. The fix for #79 restricts what may be considered a file upload rather than broadening what may be considered a normal form param to include MIME parts with a text/plain Content-Type. Rather than treating all MIME parts as form params and making a special case for file uploads by looking for a filename, we should be doing the opposite, making a special case to identify form param MIME parts by their missing filename and missing or text/plain Content-Type. jeremy