From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.229.190.149 with SMTP id di21cs62522qcb; Mon, 25 Apr 2011 07:26:44 -0700 (PDT) Return-Path: Received-SPF: pass (google.com: domain of rack-devel+bncCOCkpKnzHBCiidbtBBoEas5h1g@googlegroups.com designates 10.101.170.36 as permitted sender) client-ip=10.101.170.36; Authentication-Results: mr.google.com; spf=pass (google.com: domain of rack-devel+bncCOCkpKnzHBCiidbtBBoEas5h1g@googlegroups.com designates 10.101.170.36 as permitted sender) smtp.mail=rack-devel+bncCOCkpKnzHBCiidbtBBoEas5h1g@googlegroups.com; dkim=pass header.i=rack-devel+bncCOCkpKnzHBCiidbtBBoEas5h1g@googlegroups.com Received: from mr.google.com ([10.101.170.36]) by 10.101.170.36 with SMTP id x36mr582888ano.5.1303741603981 (num_hops = 1); Mon, 25 Apr 2011 07:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=beta; h=domainkey-signature:x-beenthere:received-spf:mime-version :in-reply-to:references:date:message-id:subject:from:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-google-group-id:list-post :list-help:list-archive:sender:list-subscribe:list-unsubscribe :content-type; bh=F+yYrL/m2dy94dhF7SGecmRGSarwVAZZeY0FbrMwmf0=; b=dmqES/DiqfUwe/CLFgdtGq55ctEyzyCOPLTXhUTy/MD2q4utKglT5kSFClUo4oq0iV RZqdECipZ+I1/t3ercUIgZinFbMIlFyyyCRIcmX3gaYU16VUf4+5Vf2CIVmqPQl+P+4o sTriAxRRx2dkhe19l+Heswt71yks7hF892ZU0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlegroups.com; s=beta; h=x-beenthere:received-spf:mime-version:in-reply-to:references:date :message-id:subject:from:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-google-group-id:list-post:list-help:list-archive:sender :list-subscribe:list-unsubscribe:content-type; b=v1fd8GPgYw3VKrxspklJlSRInTnYTuvjVsxIhzzPH4zbftvJgcRd4Qef5jNlJ18G8G Tw4Q+tFCOoF6vwbn4DcpZgmzcVgpHLbWv15/4ecPuqiT4M+J8hgx5W8eBsz339IDAAM0 5CKp7DqiFWDUbU3v3WfJfXrHRZK0TU1/mGbI0= Received: by 10.101.170.36 with SMTP id x36mr165917ano.5.1303741602297; Mon, 25 Apr 2011 07:26:42 -0700 (PDT) X-BeenThere: rack-devel@googlegroups.com Received: by 10.231.13.196 with SMTP id d4ls4300409iba.0.gmail; Mon, 25 Apr 2011 07:26:40 -0700 (PDT) Received: by 10.231.91.210 with SMTP id o18mr1635930ibm.16.1303741600583; Mon, 25 Apr 2011 07:26:40 -0700 (PDT) Received: by 10.231.91.210 with SMTP id o18mr1635929ibm.16.1303741600561; Mon, 25 Apr 2011 07:26:40 -0700 (PDT) Received: from mail-iw0-f175.google.com (mail-iw0-f175.google.com [209.85.214.175]) by gmr-mx.google.com with ESMTPS id ue9si825232icb.2.2011.04.25.07.26.40 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Apr 2011 07:26:40 -0700 (PDT) Received-SPF: pass (google.com: domain of jballanc@gmail.com designates 209.85.214.175 as permitted sender) client-ip=209.85.214.175; Received: by mail-iw0-f175.google.com with SMTP id 10so2725840iwn.34 for ; Mon, 25 Apr 2011 07:26:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.147.3 with SMTP id l3mr4856367icv.353.1303741600345; Mon, 25 Apr 2011 07:26:40 -0700 (PDT) Received: by 10.42.167.202 with HTTP; Mon, 25 Apr 2011 07:26:40 -0700 (PDT) In-Reply-To: <31236863.1318.1302679061651.JavaMail.geo-discussion-forums@yqlq3> References: <31236863.1318.1302679061651.JavaMail.geo-discussion-forums@yqlq3> Date: Mon, 25 Apr 2011 10:26:40 -0400 Message-ID: Subject: Re: Does Rack-servers block until the whole request body has been read? From: Joshua Ballanco To: rack-devel@googlegroups.com X-Original-Sender: jballanc@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jballanc@gmail.com designates 209.85.214.175 as permitted sender) smtp.mail=jballanc@gmail.com; dkim=pass (test mode) header.i=@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: multipart/alternative; boundary=90e6ba6e82e0f7adf304a1befee5 --90e6ba6e82e0f7adf304a1befee5 Content-Type: text/plain; charset=UTF-8 Hi Daniel, I faced this same issue when writing ControlTower. When a request gets handed off to the application does depend on the server in question. Mongrel waits for the entire body to be received first (even though it uses a tempfile). Passenger, on the other hand, does not wait (at least, it didn't the last time I tested it). Passenger also does not directly use a tempfile, but rather a custom request body class. If you wanted to test directly, have a look at Net::HTTP using body_stream (there seems to be some info you might use here: http://stackoverflow.com/questions/213613/buffered-multipart-form-posts-in-ruby ). Cheers, Josh On Wed, Apr 13, 2011 at 3:17 AM, Daniel Abrahamsson wrote: > Hi, > > I am working on a server that deals with large file uploads (currently > built upon Rails, with a Metal taking care of the uploads). According to the > rack-specification: > "... handler developers must buffer the input data into some rewindable > object if the underlying input stream is not rewindable". > > For Passenger and Mongrel, this means a temp file is created for the > request (at least for requests as big as those I am dealing with). > > Now, my question is, does Rack wait until all data from the client has been > read to a tempfile before passing on control to the Rack app (in this case, > Rails)? Or does it pass on control directly, and block if the application > reads data faster than the client is sending it? > > After some initial testing, it appears to me that the former is the case. > Can anyone give me advice on how to test this? Perhaps it depends on the web > server used? Perhaps on the framework? > > Thank you in advance for any advance or clarification on this matter. > > //Daniel > --90e6ba6e82e0f7adf304a1befee5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Daniel,

I faced this same issue when writing Co= ntrolTower. When a request gets handed off to the application does depend o= n the server in question. Mongrel waits for the entire body to be received = first (even though it uses a tempfile). Passenger, on the other hand, does = not wait (at least, it didn't the last time I tested it). Passenger als= o does not directly use a tempfile, but rather a custom request body class.= If you wanted to test directly, have a look at Net::HTTP using body_stream= (there seems to be some info you might use here:=C2=A0htt= p://stackoverflow.com/questions/213613/buffered-multipart-form-posts-in-rub= y).

Cheers,

Josh

On Wed, Apr 13, 2011 at 3:17 AM, Daniel Abrahamsson <hamsson@gmail.com>= wrote:
Hi,

I am working on a server that de= als with large file uploads (currently built upon Rails, with a Metal takin= g care of the uploads). According to the rack-specification:
"... handler developers must buffer the input data into some rewindabl= e object if the underlying input stream is not rewindable".

For= Passenger and Mongrel, this means a temp file is created for the request (= at least for requests as big as those I am dealing with).

Now, my question is, does Rack wait until all data from the client has = been read to a tempfile before passing on control to the Rack app (in this = case, Rails)? Or does it pass on control directly, and block if the applica= tion reads data faster than the client is sending it?

After some initial testing, it appears to me that the former is the cas= e. Can anyone give me advice on how to test this? Perhaps it depends on the= web server used? Perhaps on the framework?

Thank you in advance for= any advance or clarification on this matter.

//Daniel

--90e6ba6e82e0f7adf304a1befee5--