From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.229.190.149 with SMTP id di21cs51955qcb; Sun, 24 Apr 2011 22:08:21 -0700 (PDT) Return-Path: Received-SPF: pass (google.com: domain of rack-devel+bncCMfS4aDAFhDDg9TtBBoEHY6y0A@googlegroups.com designates 10.229.227.200 as permitted sender) client-ip=10.229.227.200; Authentication-Results: mr.google.com; spf=pass (google.com: domain of rack-devel+bncCMfS4aDAFhDDg9TtBBoEHY6y0A@googlegroups.com designates 10.229.227.200 as permitted sender) smtp.mail=rack-devel+bncCMfS4aDAFhDDg9TtBBoEHY6y0A@googlegroups.com; dkim=pass header.i=rack-devel+bncCMfS4aDAFhDDg9TtBBoEHY6y0A@googlegroups.com Received: from mr.google.com ([10.229.227.200]) by 10.229.227.200 with SMTP id jb8mr2081004qcb.43.1303708101218 (num_hops = 1); Sun, 24 Apr 2011 22:08:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=beta; h=domainkey-signature:x-beenthere:date:from:reply-to:to:message-id :subject:mime-version:x-original-sender:precedence:mailing-list :list-id:x-google-group-id:list-post:list-help:list-archive:sender :list-subscribe:list-unsubscribe:content-type; bh=yYBuVCLWrgPUv70ZHQsKZF+LKTXbyl7TBTKJqI4ybmk=; b=jXCJRgFIZUbHRoXO/vroqgaTiESt6hWVK9LbD4LWYJrxKAce7pvZsRJNWVIP40CEQt WAHXnP3insb0W8fsh0WpTT36wEjBkPqMzZrYSa8jdV91CNKWACllEiMSRQX5kNTBPqOY zAq2kSBcs28O4QZuxmGpnmPmjbHT/spow08cA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlegroups.com; s=beta; h=x-beenthere:date:from:reply-to:to:message-id:subject:mime-version :x-original-sender:precedence:mailing-list:list-id:x-google-group-id :list-post:list-help:list-archive:sender:list-subscribe :list-unsubscribe:content-type; b=riP6tVGmgpEHLfJHNFKNByRnwqkysEfeSBtqb+PUUdRwipLJomUBcCW443dyzPE9oy GmRESYrNkA+INynqLwHezgOhMNjjMB+5+GA29muyFDK0NcU3WumMVzAdBwZ+HeErvd2W N89ePhcQt2kn1zA69KQUx8aZSALbTvp/vRNZw= Received: by 10.229.227.200 with SMTP id jb8mr490372qcb.43.1303708099495; Sun, 24 Apr 2011 22:08:19 -0700 (PDT) X-BeenThere: rack-devel@googlegroups.com Received: by 10.224.176.70 with SMTP id bd6ls857393qab.5.gmail; Sun, 24 Apr 2011 22:08:18 -0700 (PDT) Received: by 10.224.17.211 with SMTP id t19mr220954qaa.16.1303708098888; Sun, 24 Apr 2011 22:08:18 -0700 (PDT) Received: by 10.224.183.200 with SMTP id ch8msqab; Wed, 13 Apr 2011 00:17:42 -0700 (PDT) Received: by 10.224.70.203 with SMTP id e11mr424357qaj.32.1302679062236; Wed, 13 Apr 2011 00:17:42 -0700 (PDT) Date: Wed, 13 Apr 2011 00:17:41 -0700 (PDT) From: Daniel Abrahamsson Reply-To: rack-devel@googlegroups.com To: rack-devel@googlegroups.com Message-ID: <31236863.1318.1302679061651.JavaMail.geo-discussion-forums@yqlq3> Subject: Does Rack-servers block until the whole request body has been read? MIME-Version: 1.0 X-Original-Sender: hamsson@gmail.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="----=_Part_1317_25995712.1302679061647" ------=_Part_1317_25995712.1302679061647 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 ------=_Part_1317_25995712.1302679061647 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,

I am working on a server that deals with large file uploads (cur= rently built upon Rails, with a Metal taking care of the uploads). Accordin= g to the rack-specification:
"... handler developers must buffer the inp= ut data into some rewindable object if the underlying input stream is not r= ewindable".

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

Now, my question is, does Rack wait until all data from the cli= ent 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 any= one give me advice on how to test this? Perhaps it depends on the web serve= r used? Perhaps on the framework?

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

//Daniel
------=_Part_1317_25995712.1302679061647--