From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.76.159.169 with SMTP id xd9csp55403oab; Thu, 17 Jul 2014 15:34:57 -0700 (PDT) Return-Path: Received-SPF: pass (google.com: domain of rack-devel+bncBD4PTDWJVIEBBD47UGPAKGQEFGBDLHA@googlegroups.com designates 10.50.57.113 as permitted sender) client-ip=10.50.57.113 Authentication-Results: mr.google.com; spf=pass (google.com: domain of rack-devel+bncBD4PTDWJVIEBBD47UGPAKGQEFGBDLHA@googlegroups.com designates 10.50.57.113 as permitted sender) smtp.mail=rack-devel+bncBD4PTDWJVIEBBD47UGPAKGQEFGBDLHA@googlegroups.com; dkim=pass header.i=@googlegroups.com X-Received: from mr.google.com ([10.50.57.113]) by 10.50.57.113 with SMTP id h17mr3223472igq.0.1405636496801 (num_hops = 1); Thu, 17 Jul 2014 15:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20120806; h=date:from:to:subject:message-id:references:mime-version:in-reply-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-disposition; bh=vMAHZnilXPm4r/R5PGcVqYCub3r8NfUH7zednl0DzvY=; b=s2vBFqAPTASWJgQPz1HrYGQvgWwR04kg4nfkQJpwOCuu1qN/asXXxKPO2SlfBJK0vj EXOQZ3rtqf232pgkyFOM4a2vE84jB65WCSdMzclURkhGLXEALq2x7kvPvzh67yJc0EJl kqBiYty+UmRETZ/vnstj2kXvsGQUQfOc9pN4jwgjqccoG4urUkn8PdP2W8rXqfREZN0a 5W95X8UpfLVdxrcZtXv1zelbrZEVBuPvvwIcuexok10DJVI8vh1FsDML0KD+MfK8gYlp 3k3ZtGBnuX6AZElob2u08DBcQpJu+YyQyMmmNcYsLxr7ytC+yYEjszmdAVmRHMD9kGmv jxEw== X-Received: by 10.50.57.113 with SMTP id h17mr438671igq.0.1405636496529; Thu, 17 Jul 2014 15:34:56 -0700 (PDT) X-BeenThere: rack-devel@googlegroups.com Received: by 10.50.164.168 with SMTP id yr8ls3783775igb.11.canary; Thu, 17 Jul 2014 15:34:55 -0700 (PDT) X-Received: by 10.66.160.34 with SMTP id xh2mr277100pab.6.1405636495494; Thu, 17 Jul 2014 15:34:55 -0700 (PDT) Received: from dcvr.yhbt.net (dcvr.yhbt.net. [64.71.152.64]) by gmr-mx.google.com with ESMTP id zs4si586236pbc.1.2014.07.17.15.34.55 for ; Thu, 17 Jul 2014 15:34:55 -0700 (PDT) Received-SPF: none (google.com: e@80x24.org does not designate permitted sender hosts) client-ip=64.71.152.64; Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id D9FCC202BE; Thu, 17 Jul 2014 22:34:54 +0000 (UTC) Date: Thu, 17 Jul 2014 22:34:54 +0000 From: Eric Wong To: rack-devel@googlegroups.com Subject: Re: rational for rewind() Message-ID: <20140717223454.GA22447@dcvr.yhbt.net> References: MIME-Version: 1.0 In-Reply-To: X-Original-Sender: e@80x24.org X-Original-Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: e@80x24.org does not designate permitted sender hosts) smtp.mail=e@80x24.org 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: , List-Unsubscribe: , Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline (resending my original message for the archives, original seems lost, Torsten already got this privately) 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. unicorn implements input like tee(1) doing lazy, rewindable buffering: http://unicorn.bogomips.org/Unicorn/TeeInput.html > 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? I don't know the rationale, but I suspect it's to make life easier for application/API authors to know the data will exist for the lifetime of the request/response cycle. But I think having rewind as part of the spec sucks. I seem to recall there was hope of getting rid of it for Rack 2 (if it ever happens). However, since I'm not sure if Rack 2 will happen, rewind can already be disabled and break spec in servers I implement: unicorn has a "rewindable_input " option (default=true): http://unicorn.bogomips.org/Unicorn/Configurator.html yahns is a tri-state: "input_buffering <:lazy|true|false>" option: http://yahns.yhbt.net/yahns_config.txt (default=true) Fwiw, rewindable_input(true) in unicorn is equivalent to input_buffering(:lazy) in yahns. This is because unicorn expects nginx to buffer for slow clients, whereas yahns does not require nginx and buffers asynchronously even with trickling clients. -- --- 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.