From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.76.159.169 with SMTP id xd9csp58374oab; Thu, 17 Jul 2014 16:44:08 -0700 (PDT) Return-Path: Received-SPF: pass (google.com: domain of rack-devel+bncBD4PTDWJVIEBBR57UGPAKGQE6IMYLGQ@googlegroups.com designates 10.50.61.145 as permitted sender) client-ip=10.50.61.145 Authentication-Results: mr.google.com; spf=pass (google.com: domain of rack-devel+bncBD4PTDWJVIEBBR57UGPAKGQE6IMYLGQ@googlegroups.com designates 10.50.61.145 as permitted sender) smtp.mail=rack-devel+bncBD4PTDWJVIEBBR57UGPAKGQE6IMYLGQ@googlegroups.com; dkim=pass header.i=@googlegroups.com X-Received: from mr.google.com ([10.50.61.145]) by 10.50.61.145 with SMTP id p17mr4136883igr.16.1405640648412 (num_hops = 1); Thu, 17 Jul 2014 16:44:08 -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=/FeFY9lxyQMyv+LuAFe/VdVW9VD0sluCU6OFkc7SniI=; b=jYGQIcjI+AtlZwyTS6SdgAT/XZi2pEP4yxgTHHS9tNtzk52Ki8sknXS6x7QQfyp3YB ypiHFtD0Mwsm3LhXiIenqr8bmVj4HzlTf0qf93lQCy26suDiHW7rTaSc2cPk5ohR+rKw 2rXodHY4gPZklOAJubwwsRGJy1D5GfzjTt276ov3zPOIFzYb1R3p6AZjVsWInJLxx7xS VFm0fQvCrsrN4Amt17Z3vUlOLQ96rLS9kRKEhi1PX3QDlD5huNLc5kC62D337pRAYDEA Wou43eLSt3/hfGekuk7s3bh7lAvPCUImCCCTRcJfCgbTYupNPZzJXAt6j58fvhmTJXiC esQg== X-Received: by 10.50.61.145 with SMTP id p17mr571213igr.16.1405640648292; Thu, 17 Jul 2014 16:44:08 -0700 (PDT) X-BeenThere: rack-devel@googlegroups.com Received: by 10.50.66.147 with SMTP id f19ls1916219igt.41.gmail; Thu, 17 Jul 2014 16:44:07 -0700 (PDT) X-Received: by 10.66.150.225 with SMTP id ul1mr470934pab.20.1405640647639; Thu, 17 Jul 2014 16:44:07 -0700 (PDT) Received: from dcvr.yhbt.net (dcvr.yhbt.net. [64.71.152.64]) by gmr-mx.google.com with ESMTP id gn8si605402pbc.0.2014.07.17.16.44.06 for ; Thu, 17 Jul 2014 16:44:06 -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 E3D3F202BE; Thu, 17 Jul 2014 23:44:05 +0000 (UTC) Date: Thu, 17 Jul 2014 23:44:05 +0000 From: Eric Wong To: rack-devel@googlegroups.com Subject: Re: rational for rewind() Message-ID: <20140717234405.GA24893@dcvr.yhbt.net> References: <20140717223454.GA22447@dcvr.yhbt.net> 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 James Tucker wrote: > > 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 > > > This is the approach I would take. I'm not sure if TeeInput supports it, > but for a generic server supporting websocket type use cases, I'd add a > discardable buffer API too, so you can "hijack" the input stream and > release any stale resources. I'm not completely sure what you mean[1], but both yahns and unicorn support rack.hijack. TeeInput cannot read beyond the current HTTP request boundary, so I'm not sure there's anything that needs to change in the HTTP servers. If a client pipelines non-HTTP data after a normal HTTP request, that would be a problem; but pipelining during a protocol change/negotiation seems wrong to begin with. [1] I've not tried rack.hijack with websockets, yet I just (hopefully) implemented it according to the Rack spec. GUI-oriented websocket things just do not interest me. -- --- 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.