From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.25.208.212 with SMTP id h203csp2514377lfg; Mon, 2 Feb 2015 13:27:00 -0800 (PST) Return-Path: Received-SPF: pass (google.com: domain of rack-devel+bncBDVZBRNGRYLRBIWXX6TAKGQEHJ2M4II@googlegroups.com designates 10.140.84.84 as permitted sender) client-ip=10.140.84.84 Authentication-Results: mr.google.com; spf=pass (google.com: domain of rack-devel+bncBDVZBRNGRYLRBIWXX6TAKGQEHJ2M4II@googlegroups.com designates 10.140.84.84 as permitted sender) smtp.mail=rack-devel+bncBDVZBRNGRYLRBIWXX6TAKGQEHJ2M4II@googlegroups.com; dkim=pass header.i=@gmail.com X-Received: from mr.google.com ([10.140.84.84]) by 10.140.84.84 with SMTP id k78mr3055192qgd.25.1422912419947 (num_hops = 1); Mon, 02 Feb 2015 13:26:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20120806; h=date:from:to:message-id:subject:mime-version:content-type :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:sender:list-subscribe :list-unsubscribe; bh=BqZ3gT4QSP+RWSX23tFVpvpo9sPFX9Vu/riWFFioVHA=; b=eurwGwhbxJbe30qgf+PLqHk2iQf415pbSQ9RPe6mT6/jB1DJ21Yku3WEyrAqdXSHFY mrXewUgf0LijmBJ5lK8keLYD8Azw2K7RMWrNdrRErFpHlRctuE1ZbZZxOQ7sGvaTY4Lz WjDl4D6mP6ZkTLuGCoroGnNSj0NY+EpiNNDbeumL8BzP/Z/PBN21YDmb/F91Y0yMjxg1 JSOrWIbIcKmZHgSsei/vNphbVJCVOq9D8wzUifwXS20H2IbtJmCZ5ay9rUzX0qaGoVk9 GcpOqWIKY/FyjFkUUucpiLTvcha6aEXt+vhJRxMbMyzC/uoP7Kh8m41+8QImyhTjWde4 NKzw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:subject:mime-version:content-type :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:sender:list-subscribe :list-unsubscribe; bh=BqZ3gT4QSP+RWSX23tFVpvpo9sPFX9Vu/riWFFioVHA=; b=u7V2mQuHkagx2XAjnsBUHAEwIr9hDx/QgHIJaDHgE604/GCYGRTm2Iipl19ZnIcRaq 7nzLzqZ+oPRpB4RuDHxd/3jZsDsk0+cKJw0scs8d4m2guqGHO5W7UyNRLQ7LFuRPgbAP AFxsY7lHnGIXkb3LOLTAC8bS/tWLH14FSTf9HLFah3RVxbHnYe1nYbFFHrFoQ1yqp6hd Q27q+WlufDBOpkB+0Q1dbKZDAy3Q10h4XtFSWfa1neoDTC5LZWPe2AMPQeo8Ewoata2d iTfh7M+qtTRHIbQoH1aZ8dhE/c4leewChD0s8WhJRbD00Y2JO6CoCqc+PqNpMeevJA3U QprQ== X-Received: by 10.140.84.84 with SMTP id k78mr244995qgd.25.1422912419424; Mon, 02 Feb 2015 13:26:59 -0800 (PST) X-BeenThere: rack-devel@googlegroups.com Received: by 10.140.82.112 with SMTP id g103ls720547qgd.66.gmail; Mon, 02 Feb 2015 13:26:58 -0800 (PST) X-Received: by 10.140.92.146 with SMTP id b18mr256025qge.36.1422912418827; Mon, 02 Feb 2015 13:26:58 -0800 (PST) Date: Mon, 2 Feb 2015 13:26:58 -0800 (PST) From: Hongli Lai To: rack-devel@googlegroups.com Message-Id: <6816caae-e47e-4e9d-9897-70c2069200a0@googlegroups.com> Subject: Close body object after socket hijacking or not? MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_843_164005532.1422912418395" X-Original-Sender: honglilai@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: , List-Unsubscribe: , ------=_Part_843_164005532.1422912418395 Content-Type: multipart/alternative; boundary="----=_Part_844_1219457223.1422912418395" ------=_Part_844_1219457223.1422912418395 Content-Type: text/plain; charset=UTF-8 Some users are experiencing problems with Rack::Lock and socket hijacking in combination with some servers, such as Phusion Passenger. They've noticed that when Rack::Lock is used in a request that hijacks the socket, the next request fails with "deadlock; recursive locking" inside Rack::Lock. I've posted the results of my investigation here: https://github.com/ngauthier/tubesock/issues/10#issuecomment-72539461. But the bottom line is that different servers handle the response body object differently in the face of socket hijacking. So I'd like to have clarification on the following question: are servers supposed to call #close on the body object or not, after the request as been hijacked? The way the specification is currently written is ambiguous. It seems to imply that servers must only call #close on the body object if the request was partially hijacked, but not when the request was fully hijacked. -- --- 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_844_1219457223.1422912418395 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Some users are experiencing problems with Rack::Lock and s= ocket hijacking in combination with some servers, such as Phusion Passenger= . They've noticed that when Rack::Lock is used in a request that hijacks th= e socket, the next request fails with "deadlock; recursive locking" inside = Rack::Lock.

I've posted the results of my investigation = here: https://github.com/ngauthier/tubesock/issues/10#issuecomment-725= 39461. But the bottom line is that different servers handle the response bo= dy object differently in the face of socket hijacking.

So I'd like t= o have clarification on the following question: are servers supposed to cal= l #close on the body object or not, after the request as been hijacked? The= way the specification is currently written is ambiguous. It seems to imply= that servers must only call #close on the body object if the request was p= artially hijacked, but not when the request was fully hijacked.
<= /div>

--

---
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_844_1219457223.1422912418395-- ------=_Part_843_164005532.1422912418395--