From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.76.159.169 with SMTP id xd9csp7597oab; Sat, 19 Jul 2014 02:55:55 -0700 (PDT) Return-Path: Received-SPF: pass (google.com: domain of rack-devel+bncBCPP5HNTQUDRBKUBVGPAKGQEIOEJDTA@googlegroups.com designates 10.140.34.168 as permitted sender) client-ip=10.140.34.168 Authentication-Results: mr.google.com; spf=pass (google.com: domain of rack-devel+bncBCPP5HNTQUDRBKUBVGPAKGQEIOEJDTA@googlegroups.com designates 10.140.34.168 as permitted sender) smtp.mail=rack-devel+bncBCPP5HNTQUDRBKUBVGPAKGQEIOEJDTA@googlegroups.com; dkim=pass header.i=@googlegroups.com X-Received: from mr.google.com ([10.140.34.168]) by 10.140.34.168 with SMTP id l37mr1400091qgl.3.1405763754865 (num_hops = 1); Sat, 19 Jul 2014 02:55:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20120806; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:sender:list-subscribe :list-unsubscribe:content-type; bh=omNHhgmD0K1si4XZR3nF3W7WvMcTwDFNfwiDjDV7ikg=; b=NCJD7dFh9fKrEy0kFT3ku988WX0Ak4VoFbs2WZhUiTD+3xXRPOwsHPYR6wawYTip80 6qYTD+X091oSh8bA/hEf5xkENO15KqYnfuI+qFyRY8FSh6x+CgzZmmR4jviNb6ct5Q3l F9OOYtloefCfDnofjRdQnVXVoFsRiyeZvlt2EDJC6ay+FKJi6eAfwytWb7qUUeRLgbIq iBfz3c0jdaeU1cAsw1j9Zszje8FVOPRPsZJ607EyRMJtM6flIBFKogkly7lBW/ssLV/I SgONqxtw9XoZGD+aBye/thesLzWBtcc07Xmb521mrSpgRPUIMVjVQZT6k/6yslTSvGv1 kHuw== X-Received: by 10.140.34.168 with SMTP id l37mr150569qgl.3.1405763754673; Sat, 19 Jul 2014 02:55:54 -0700 (PDT) X-BeenThere: rack-devel@googlegroups.com Received: by 10.140.97.198 with SMTP id m64ls1283604qge.39.gmail; Sat, 19 Jul 2014 02:55:54 -0700 (PDT) X-Received: by 10.140.93.181 with SMTP id d50mr146177qge.0.1405763754024; Sat, 19 Jul 2014 02:55:54 -0700 (PDT) Date: Sat, 19 Jul 2014 02:55:52 -0700 (PDT) From: Torsten Robitzki To: rack-devel@googlegroups.com Message-Id: <082b48f0-dfdc-470f-83d9-123bd54f48d9@googlegroups.com> In-Reply-To: References: <20140717223454.GA22447@dcvr.yhbt.net> Subject: Re: rational for rewind() MIME-Version: 1.0 X-Original-Sender: torsten@robitzki.de 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: multipart/alternative; boundary="----=_Part_60_1442919710.1405763752829" ------=_Part_60_1442919710.1405763752829 Content-Type: text/plain; charset=UTF-8 Hello, Am Freitag, 18. Juli 2014 01:10:03 UTC+2 schrieb raggi: > Agreed. I generally think a lot of concerns that used to be in middleware > should not be so (e.g. chunking and content-length), but this concern > actually could be handled by middleware so apps that want it can add it in > the appropriate place in the chain. This would remove the responsibility > from the server authors, which opens up a lot of potential optimizations > and flexibility. We also lack a lot of potentially useful security > considerations in this area (i.e. both static and dynamic configurable > limits). > depending on how much middlewares need this feature, it might be more effective to implement the buffering in the server as this is the part of the stack that is nearest to the metal. Maybe we could propose an API for middle wares that need rewinding and then do a reference implementation that could be implemented naively in ruby and added onto of all existing server implementations. I think such an API needs to address: - that in case that no middleware needs to rewind, the input needs not to be buffered - in case the middlewares just need to peek into the beginning of the input, only that beginning of the stream have to be buffered. - it should as backward compatible as possible. At least no middleware that does not use rewind() should see a difference. regards, Torsten -- --- 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. ------=_Part_60_1442919710.1405763752829 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

Am Freitag, 18. Juli 2014 01:10:03 UTC+2 sch= rieb raggi:
 
Agreed. I generally thi= nk a lot of concerns that used to be in middleware should not be so (e.g. c= hunking and content-length), but this concern actually could be handled by = middleware so apps that want it can add it in the appropriate place in the = chain. This would remove the responsibility from the server authors, which = opens up a lot of potential optimizations and flexibility. We also lack a l= ot of potentially useful security considerations in this area (i.e. both st= atic and dynamic configurable limits).
=

depending on how much middlewares need this feature, it= might be more effective to implement the buffering in the server as this i= s the part of the stack that is nearest to the metal. 

<= /div>
Maybe we could propose an API for middle wares that need rewindin= g and then do a reference implementation that could be implemented naively = in ruby and added onto of all existing server implementations. I think such= an API needs to address:
- that in case that no middleware needs= to rewind, the input needs not to be buffered
- in case the midd= lewares just need to peek into the beginning of the input, only that beginn= ing of the stream have to be buffered.
- it should as backward co= mpatible as possible. At least no middleware that does not use rewind() sho= uld see a difference.

regards,
Torsten
 

--

---
You received this message because you are subscribed to the Google Groups &= quot;Rack Development" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to rack-dev= el+unsubscribe@googlegroups.com.
For more options, visit http= s://groups.google.com/d/optout.
------=_Part_60_1442919710.1405763752829--