From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.239.138.72 with SMTP id o8cs53544hbo; Fri, 9 Jul 2010 16:49:37 -0700 (PDT) Return-Path: Received-SPF: pass (google.com: domain of rack-devel+bncCOCkpKnzHBCP697hBBoEUHf9-A@googlegroups.com designates 10.101.73.3 as permitted sender) client-ip=10.101.73.3; Authentication-Results: mr.google.com; spf=pass (google.com: domain of rack-devel+bncCOCkpKnzHBCP697hBBoEUHf9-A@googlegroups.com designates 10.101.73.3 as permitted sender) smtp.mail=rack-devel+bncCOCkpKnzHBCP697hBBoEUHf9-A@googlegroups.com; dkim=pass header.i=rack-devel+bncCOCkpKnzHBCP697hBBoEUHf9-A@googlegroups.com Received: from mr.google.com ([10.101.73.3]) by 10.101.73.3 with SMTP id a3mr6307512anl.60.1278719376427 (num_hops = 1); Fri, 09 Jul 2010 16:49:36 -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:received-spf:received:x-auditid:received :references:in-reply-to:mime-version:message-id:from:subject:date:to :x-mailer:x-brightmail-tracker: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=sreTwWcs0kiDTJNfQNFPr7eYVw5I1rTHo5s8Y4N61Lg=; b=JnMfb6pKH6dM5l52w34x5awSOz9kCLmd4cFDkyxqW/4M+sQnayN8+rt2bmcGDle3mq liwDRVt/ADYvHK2bFZNeofAAFY+OyFsbdnXP6liivQsfMIUctvc/cpGMrP1IP2PVoyYY FgI18k/w6PmwipSHYnOGsjPuBaQKyIVLsesNw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlegroups.com; s=beta; h=x-beenthere:received-spf:x-auditid:references:in-reply-to :mime-version:message-id:from:subject:date:to:x-mailer :x-brightmail-tracker: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=GeL7xMvMiOhf0sdMHpDthbVSJNdz77WyKbFxv+AsfbRvgTScAVFwqzCl/A8sz5vrCO PPE9+lCxY/0BYBCVuAXG/UksjJSWieGYxTWf1NJGowWWTvX3PnSBDKUC2T3rzKiac+hG TnLhIp00TETaZ3szf0+eGCf4947FUISxDUDDM= Received: by 10.101.73.3 with SMTP id a3mr1123814anl.60.1278719375217; Fri, 09 Jul 2010 16:49:35 -0700 (PDT) X-BeenThere: rack-devel@googlegroups.com Received: by 10.101.156.10 with SMTP id i10ls465025ano.3.p; Fri, 09 Jul 2010 16:49:34 -0700 (PDT) Received: by 10.101.131.38 with SMTP id i38mr2681469ann.8.1278719374389; Fri, 09 Jul 2010 16:49:34 -0700 (PDT) Received: by 10.142.215.8 with SMTP id n8mr1612238wfg.32.1278565398362; Wed, 07 Jul 2010 22:03:18 -0700 (PDT) Received: by 10.142.215.8 with SMTP id n8mr1612237wfg.32.1278565398340; Wed, 07 Jul 2010 22:03:18 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by gmr-mx.google.com with ESMTP id b2si380785rvn.6.2010.07.07.22.03.18; Wed, 07 Jul 2010 22:03:18 -0700 (PDT) Received-SPF: neutral (google.com: 17.254.13.22 is neither permitted nor denied by domain of jballanc@gmail.com) client-ip=17.254.13.22; Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id 0E5329C69A97 for ; Wed, 7 Jul 2010 22:03:18 -0700 (PDT) X-AuditID: 11807134-b7b53ae000005755-d7-4c355c13e3f2 Received: from vp0101wa-dhcp173.apple.com (vp0101wa-dhcp173.apple.com [17.224.23.173]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id 4E.82.22357.51C553C4; Wed, 7 Jul 2010 22:03:17 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1081) Message-Id: <3652BCFA-B7DA-423A-84C9-77BCDF75931D@gmail.com> From: Joshua Ballanco Subject: Re: Consider reverting multipart parsing change Date: Wed, 7 Jul 2010 22:03:14 -0700 To: rack-devel@googlegroups.com X-Mailer: Apple Mail (2.1081) X-Brightmail-Tracker: AAAAAQAAAZE= X-Original-Sender: jballanc@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 17.254.13.22 is neither permitted nor denied by domain of jballanc@gmail.com) smtp.mail=jballanc@gmail.com 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=us-ascii Content-Transfer-Encoding: quoted-printable On Jul 6, 2010, at 12:54 AM, Jeremy Kemper wrote: > 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). It seemed best to = me >> that tempfiles only be used in the case of having a filename = attribute >> be present, regardless of content-type. Your 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. I guess my >> question is, why not just use the filename attribute to drive this >> logic? I 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). >=20 > 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. >=20 > 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. >=20 > 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. Just wanted to give my +1 to this solution. I actually have a real-life = use case where this becomes an issue. I have a client (not a web = browser) which generates data dynamically to upload to an HTTP server as = a file upload. Because there was no original file from which to extract = a filename parameter (and because the server has logic to assign = filenames based on other parameters), my client does a multipart-upload = without a filename parameter. However, the file parts can be rather = large (up to 100s of MB). Having these passed in as strings instead of = using tempfiles seems less than ideal. Cheers, Josh=