From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.76.94.227 with SMTP id df3csp4818oab; Fri, 23 May 2014 03:46:59 -0700 (PDT) Return-Path: Received-SPF: pass (google.com: domain of rack-devel+bncBC7JX4G6SUEBBHWO7SNQKGQEKQCQGEQ@googlegroups.com designates 10.180.105.2 as permitted sender) client-ip=10.180.105.2 Authentication-Results: mr.google.com; spf=pass (google.com: domain of rack-devel+bncBC7JX4G6SUEBBHWO7SNQKGQEKQCQGEQ@googlegroups.com designates 10.180.105.2 as permitted sender) smtp.mail=rack-devel+bncBC7JX4G6SUEBBHWO7SNQKGQEKQCQGEQ@googlegroups.com; dkim=pass header.i=@googlegroups.com X-Received: from mr.google.com ([10.180.105.2]) by 10.180.105.2 with SMTP id gi2mr82965wib.19.1400842019270 (num_hops = 1); Fri, 23 May 2014 03:46:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20120806; h=mime-version:in-reply-to:references:from:date:message-id:subject: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; bh=qEBjjZ2Mp/aCrSiCjmmezVlDquyz7anrxZP2mBC/YL0=; b=fBeeIwrj8t23HK7mB6RxGClHMNjlS46fU1S7jHuvgydCLfkwYmDKzbOT7+tOARvNYK QO4Apy5mTEKLyP9+IEZzEZ5gGyrqxdL9fcvr13z3viepqsB0thr6KKirUpF6f/ae0DFY dZYS6Dp0zLHq1S+oCqmSdmUVKWVbxKTmTZtfB7jbk4lFkonqNa1l6/fmPGYEdjoNldCA 3ibPUP6V24WC9d6MW2fBj6XgQh5t7cNn/qGzSLlwR6XMEtw5jNm7jN9k3JzHzIZioEEz 6czHmg0f/9QRNKOLZZ4erdf70kDvwvsqdqrnYloHBYleCJneKO+ZacFYkHES6QOSy1M1 R2Yg== X-Received: by 10.180.105.2 with SMTP id gi2mr6965wib.19.1400842018793; Fri, 23 May 2014 03:46:58 -0700 (PDT) X-BeenThere: rack-devel@googlegroups.com Received: by 10.180.186.8 with SMTP id fg8ls72418wic.7.gmail; Fri, 23 May 2014 03:46:54 -0700 (PDT) X-Received: by 10.14.198.200 with SMTP id v48mr223422een.5.1400842014091; Fri, 23 May 2014 03:46:54 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [2a00:1450:4010:c03::230]) by gmr-mx.google.com with ESMTPS id r49si1112629eep.0.2014.05.23.03.46.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 May 2014 03:46:54 -0700 (PDT) Received-SPF: pass (google.com: domain of judofyr@gmail.com designates 2a00:1450:4010:c03::230 as permitted sender) client-ip=2a00:1450:4010:c03::230; Received: by mail-la0-f48.google.com with SMTP id mc6so3933250lab.21 for ; Fri, 23 May 2014 03:46:53 -0700 (PDT) X-Received: by 10.112.129.202 with SMTP id ny10mr2735448lbb.14.1400842013712; Fri, 23 May 2014 03:46:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.136.136 with HTTP; Fri, 23 May 2014 03:46:33 -0700 (PDT) In-Reply-To: References: From: Magnus Holm Date: Fri, 23 May 2014 12:46:33 +0200 Message-ID: Subject: Re: rational for rewind() To: rack-devel X-Original-Sender: judofyr@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of judofyr@gmail.com designates 2a00:1450:4010:c03::230 as permitted sender) smtp.mail=judofyr@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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: X-Google-Group-Id: 486215384060 List-Post: , List-Help: , List-Archive: Sender: rack-devel@googlegroups.com List-Subscribe: , List-Unsubscribe: , Content-Type: text/plain; charset=UTF-8 On Thu, May 22, 2014 at 11:12 PM, Torsten Robitzki wrote: > Hello, > I'm implementing a C++ comet web server, that (tries) to implement rack to > adapt ruby applications. Currently I'm reading a body very naively put the > body into a ruby String and wrap it with a StringIO to provide the > rack.input for the implementation. As I'm going to use the server for > uploading images, I would like to implement a real, stream-like object to > circumvent the need to buffer the POST body before handing it to the > application. > > Now, I've read the rack specs and read about rewind(). To implement > rewind(), I would have to store the whole body, even when the upstream > application just calculates some kind of checksum on the body, or uploads it > to s3. What's the rational behind this part of the specification? Is it > possible to not implement rewind() and to tell applications that need > rewind(), to keep there own copy of the body, in case it is needed? > > kind regards, > Torsten One word: Middleware. Some middleware need to access the HTTP body (e.g. for fetching the CSRF-token from a POST-parameter). In order to allow middleware to process HTTP bodies, rewind() was added. Yes, we are all aware of the issues it present. Yes, it sucks. Yes, you can implement a server which doesn't support rewind(), but it won't work with many middleware. // Magnus Holm -- --- You received this message because you are subscribed to the Google Groups "Rack Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout.