From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.204.72.79 with SMTP id l15cs182287bkj; Mon, 15 Jun 2009 21:56:27 -0700 (PDT) Return-Path: Received-SPF: pass (google.com: domain of grbounce-ceibQwUAAAB4YPBqaDIjI2bFOCxyyh3G=chneukirchen=gmail.com@googlegroups.com designates 10.220.73.67 as permitted sender) client-ip=10.220.73.67; Authentication-Results: mr.google.com; spf=pass (google.com: domain of grbounce-ceibQwUAAAB4YPBqaDIjI2bFOCxyyh3G=chneukirchen=gmail.com@googlegroups.com designates 10.220.73.67 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.220.73.67]) by 10.220.73.67 with SMTP id p3mr6157389vcj.7.1245128186328 (num_hops = 1); Mon, 15 Jun 2009 21:56:26 -0700 (PDT) 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:received:date:x-ip: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=6SqzTcaYZsPV3vqgScsdeNXQAQhNZg11iqxmq/IoTeU=; b=K2TS4fz4fC4/2ReREV6l/J7YvMolQ0Sg5RBS40LznJkCnv7IH2FW0hUgbrKXpNHwY2 3ZWWZA3c8KQw/BstirZQ0Ibwocw+3zd9Ov91JRhkM0TdwE4PjrWwc31bmfNNI6DEXiXf pcM2d/DgxCg0NrhuIT4AnglyqZScBalYsP5ok= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlegroups.com; s=beta; h=x-sender:x-apparently-to:mime-version:content-type:date:x-ip :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=0GXGIm636yx+4Ds6ICxk6nM4ZA5a/b2mFYcozQBugTHPlrt9yRUjhHSKZg9ITfJ3wy PmNPxgLCtwhkZfKFkW7iWhfdEOk4IcJrVRajPmTZhGQq1Mcsw+3o3H3fa6EB2P3FwzEA OeONeqAV7kcO2aJAp2GoxDkkBmxdcPDkfZ/TA= Received: by 10.220.73.67 with SMTP id p3mr831094vcj.7.1245128130387; Mon, 15 Jun 2009 21:55:30 -0700 (PDT) Received: by 10.230.18.20 with SMTP id u20gr1455vba.0; Mon, 15 Jun 2009 21:55:29 -0700 (PDT) X-Sender: simon.a.chiang@gmail.com X-Apparently-To: rack-devel@googlegroups.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Received: by 10.151.68.13 with SMTP id v13mr5933ybk.3.1245127439146; Mon, 15 Jun 2009 21:43:59 -0700 (PDT) Date: Mon, 15 Jun 2009 21:43:59 -0700 (PDT) X-IP: 71.208.162.25 User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.11) Gecko/2009060214 Firefox/3.0.11,gzip(gfe),gzip(gfe) Message-ID: Subject: Parsing non-nested requests From: Simon Chiang To: Rack Development X-Google-Approved: m.fellinger@gmail.com via web at 2009-06-16 04:55:28 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 I have run into situations where I'd like to parse requests in an non- nested fashion. Rack::Request almost lets you do this, but not quite. I propose the changes in this commit: http://github.com/bahuvrihi/rack/commit/fa29dc523a0994a85686b01a192d3ccbfb36c183 The commit refactors Rack::Request so that the parsing methods for query strings and multipart data may be overridden. Then for non- multipart data I think everything is fine; you would simply subclass Request and call Utils.parse_query instead of Utils.parse_nested_query. Multipart data requires a little patch though because as far as I can tell Multipart.parse_multipart parses nested queries and you can't get around that. I also propose the changes in this commit: http://github.com/bahuvrihi/rack/commit/d6a2a162651c8068822a9370fe66eeb709a5d69c The commit adds a flag to parse_multipart to allow non-nested parsing. The flag is a little inelegant, but at least it's backwards compatible. A more elegant solution would be to have parse_multipart and parse_nested_multipart, but that would be bad for anyone that expects the current behavior. Any thoughts?