From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.239.138.72 with SMTP id o8cs58761hbo; Fri, 9 Jul 2010 19:26:41 -0700 (PDT) Return-Path: Received-SPF: pass (google.com: domain of rack-devel+bncCJTC9snpGRDftN_hBBoEZbEBWQ@googlegroups.com designates 10.229.106.197 as permitted sender) client-ip=10.229.106.197; Authentication-Results: mr.google.com; spf=pass (google.com: domain of rack-devel+bncCJTC9snpGRDftN_hBBoEZbEBWQ@googlegroups.com designates 10.229.106.197 as permitted sender) smtp.mail=rack-devel+bncCJTC9snpGRDftN_hBBoEZbEBWQ@googlegroups.com; dkim=pass header.i=rack-devel+bncCJTC9snpGRDftN_hBBoEZbEBWQ@googlegroups.com Received: from mr.google.com ([10.229.106.197]) by 10.229.106.197 with SMTP id y5mr5712505qco.36.1278728800819 (num_hops = 1); Fri, 09 Jul 2010 19:26:40 -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:received:received:message-id:from:to :in-reply-to:mime-version:subject:date:references:x-mailer :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=uluBEad3aUdS9n9TvgTs+te1B/uIP/9N5UFFsypWcHc=; b=Qzgj4n94isO1yWzMVmGhU8hYYyCTVh2X5C8PqgisSWmbGKTq/8Bms1B+UWv712Jhkz NgBBNb0nKR282zWnFT+Vf5mqYUXRlWYZkKtb52jKCT+3ePEwqNDtEC2hUbP8Yph3huNY B92Ga4UkaSTb/mbp/zdHplg0TI7gHsPTc27U0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlegroups.com; s=beta; h=x-beenthere:received-spf:message-id:from:to:in-reply-to :mime-version:subject:date:references:x-mailer: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=zjlWIBcL+ttrHzXihFEEvQ2eLveF2r3nyiaPB4rCKn+NBXGg65APne0dRrYp0rJb2F y3B7TOUsTDpnh8NWs4xQHvBlhri9S/FqUqK2qxSMSAIMeTa9O8MpJYgxyiuFO4MyO2hu IdglPr8q3YlvTbcmF6wO83jMypC37fwDidOPs= Received: by 10.229.106.197 with SMTP id y5mr1140052qco.36.1278728799624; Fri, 09 Jul 2010 19:26:39 -0700 (PDT) X-BeenThere: rack-devel@googlegroups.com Received: by 10.229.247.2 with SMTP id ma2ls424140qcb.0.p; Fri, 09 Jul 2010 19:26:38 -0700 (PDT) Received: by 10.229.185.202 with SMTP id cp10mr143337qcb.16.1278728798114; Fri, 09 Jul 2010 19:26:38 -0700 (PDT) Received: by 10.229.185.202 with SMTP id cp10mr143336qcb.16.1278728798096; Fri, 09 Jul 2010 19:26:38 -0700 (PDT) Received: from mail-qy0-f177.google.com (mail-qy0-f177.google.com [209.85.216.177]) by gmr-mx.google.com with ESMTP id x40si912139qce.7.2010.07.09.19.26.37; Fri, 09 Jul 2010 19:26:37 -0700 (PDT) Received-SPF: pass (google.com: domain of mateo.murphy@gmail.com designates 209.85.216.177 as permitted sender) client-ip=209.85.216.177; Received: by qyk1 with SMTP id 1so3822782qyk.1 for ; Fri, 09 Jul 2010 19:26:37 -0700 (PDT) Received: by 10.224.43.100 with SMTP id v36mr6087900qae.201.1278728796815; Fri, 09 Jul 2010 19:26:36 -0700 (PDT) Received: from [192.168.1.101] (modemcable232.153-58-74.mc.videotron.ca [74.58.153.232]) by mx.google.com with ESMTPS id i26sm6836199qcm.43.2010.07.09.19.26.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 09 Jul 2010 19:26:35 -0700 (PDT) Message-Id: <2835882E-CC4E-4596-8EFF-99A8D17BCDCE@gmail.com> From: Mateo Murphy To: rack-devel@googlegroups.com In-Reply-To: <3652BCFA-B7DA-423A-84C9-77BCDF75931D@gmail.com> Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: Consider reverting multipart parsing change Date: Fri, 9 Jul 2010 22:26:33 -0400 References: <3652BCFA-B7DA-423A-84C9-77BCDF75931D@gmail.com> X-Mailer: Apple Mail (2.936) X-Original-Sender: mateo.murphy@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of mateo.murphy@gmail.com designates 209.85.216.177 as permitted sender) smtp.mail=mateo.murphy@gmail.com; dkim=pass (test mode) header.i=@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; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 8-Jul-10, at 1:03 AM, Joshua Ballanco wrote: > 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). >> >> 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. > > 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 Looking at the relevant RFC (http://www.ietf.org/rfc/rfc1867.txt), the filename is clearly optional, so relying on it is not a good idea. Treating everything that has a filename or a content-type other than text/plain as a file would be a sensible solution, although that creates a problem when trying to upload very large text files; in that case I think also added a content-length check might be wise?