From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.140.141.15 with SMTP id o15cs56966rvd; Tue, 5 Jan 2010 12:58:03 -0800 (PST) Received: from mr.google.com ([10.229.122.146]) by 10.229.122.146 with SMTP id l18mr26110093qcr.26.1262725082147 (num_hops = 1); Tue, 05 Jan 2010 12:58:02 -0800 (PST) Received: by 10.229.122.146 with SMTP id l18mr4455362qcr.26.1262725080770; Tue, 05 Jan 2010 12:58:00 -0800 (PST) X-BeenThere: rack-devel@googlegroups.com Received: by 10.229.100.199 with SMTP id z7ls364575qcn.0.p; Tue, 05 Jan 2010 12:57:59 -0800 (PST) Received: by 10.229.50.70 with SMTP id y6mr4556007qcf.5.1262725079457; Tue, 05 Jan 2010 12:57:59 -0800 (PST) Received: by 10.229.50.70 with SMTP id y6mr4556006qcf.5.1262725079428; Tue, 05 Jan 2010 12:57:59 -0800 (PST) Return-Path: Received: from mail-qy0-f189.google.com (mail-qy0-f189.google.com [209.85.221.189]) by gmr-mx.google.com with ESMTP id 18si6284371qyk.9.2010.01.05.12.57.58; Tue, 05 Jan 2010 12:57:58 -0800 (PST) Received-SPF: pass (google.com: domain of rtomayko@gmail.com designates 209.85.221.189 as permitted sender) client-ip=209.85.221.189; Received: by mail-qy0-f189.google.com with SMTP id 27so7028728qyk.20 for ; Tue, 05 Jan 2010 12:57:58 -0800 (PST) MIME-Version: 1.0 Sender: rack-devel@googlegroups.com Received: by 10.224.99.134 with SMTP id u6mr12399622qan.184.1262725078271; Tue, 05 Jan 2010 12:57:58 -0800 (PST) In-Reply-To: References: <200912092359.08240.ibc@aliax.net> <200912100015.17445.ibc@aliax.net> Date: Tue, 5 Jan 2010 12:57:58 -0800 Message-ID: Subject: Re: Why env.object_id is different in each middleware? From: Ryan Tomayko To: rack-devel@googlegroups.com X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of rtomayko@gmail.com designates 209.85.221.189 as permitted sender) smtp.mail=rtomayko@gmail.com; dkim=pass (test mode) header.i=@gmail.com X-Original-Sender: r@tomayko.com Reply-To: rack-devel@googlegroups.com Precedence: list Mailing-list: list rack-devel@googlegroups.com; contact rack-devel+owners@googlegroups.com List-ID: List-Post: , List-Help: , List-Archive: X-Thread-Url: http://groups.google.com/group/rack-devel/t/5d93266373a372ea X-Message-Url: http://groups.google.com/group/rack-devel/msg/3d2c7f0a5559a5ff List-Unsubscribe: , List-Subscribe: , Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Jan 3, 2010 at 4:50 PM, Tim Carey-Smith wrote: > On 10/12/2009, at 12:15 PM, I=C3=B1aki Baz Castillo wrote: > >> El Mi=C3=A9rcoles, 9 de Diciembre de 2009, I=C3=B1aki Baz Castillo escri= bi=C3=B3: >>> >>> Since env is a hash I cannot understand why its object_id changes. Any >>> explanation for it? >>> This explains that when I change env[XXX] into my final appplication >>> MyApp.handle_request the change doesn't exist after calling >>> resp =3D @app.call(env) >>> in the first middleware. >> >> If I add a env["LALA"] in the first middleware then it's visible for >> following >> middlewares. >> However if I add env["LOLO"] in the second middleware this is not visibl= e >> for >> first middleware after calling "@app.call(env)". >> >> Is it the expected behavior? >> >> Thanks. > > Hi there, > > I've hit this before. This is because you are using Rack::URLMap (via > Builder#map). > The inner app is called with a new env hash. > >> diff --git a/lib/rack/urlmap.rb b/lib/rack/urlmap.rb >> index b699d35..3374535 100644 >> --- a/lib/rack/urlmap.rb >> +++ b/lib/rack/urlmap.rb >> @@ -45,7 +45,7 @@ module Rack >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 next unless rest.empty? || rest[0] =3D=3D ?/ >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 return app.call( >> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0env.merge( >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0env.merge!( >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 'SCRIPT_NAME' =3D> (script_nam= e + location), >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 'PATH_INFO' =C2=A0 =3D> rest)) >> =C2=A0 =C2=A0 =C2=A0 } > > Is this patch useful? > Is it useful to assume that a request will only have a single env hash? > Will it make Rack::Cascade and friends behave incorrectly? > > Should URLMap revert the change in an ensure to allow subsequent requests= to > function? This is something I've always thought should be included in the rack spec. Should a rack component, A, that calls another component, B, be able to assume that env modifications made by B (or downstream) will be visible in the env passed by A when B returns? As of right now, there's a number of core and contrib middleware that assume: no. The URLMap example above is a good one. A lot of middleware pass a copy of the env downstream instead of modifying and relaying the env provided. I see this come up fairly often but I'm not sure there's ever been a good use case for it. It's usually a sign that you're using the env where you should be using the response tuple. e.g., instead of putting something in the env, put it in the response headers or convey it via status code. Or maybe this really is something the env could be useful for and I've just never run into a good case. Can anyone provide real examples of where it would be necessary? Thanks, Ryan