Rack Development Google Group

Re: [PATCH 0/3] support reuse of HeaderHash objects

2010-01-05T23:58:45Z

Ugh, this series interacts badly with applications and frameworks that
set cookies without using Rack::Utils. Rails 2.3.5 is one (popular)
example of a framework that sets cookies without help from Rack::Utils.
Below is a patch (against Rails 2.3.5) that pinpoints and fixes the
problematic code: (I don't expect this patch to be applied)

Re: Why env.object_id is different in each middleware?

2010-01-05T23:47:41Z

My real case:
I want to use Clogger to log the authenticated user ($env["REMOTE_USER"]).
Clogger expects that it runs after an authentication middleware which adds
such env entry. However in my case I need to decide the "remote_user" in the
final Rack application so I need that changes done in env by the last Rack

Re: Why env.object_id is different in each middleware?

2010-01-05T20:57:58Z

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

Rack with SOAP integration

2010-01-05T07:17:49Z

Hi All,
I am new to Rack. I am ROR developer. I have to work SOAP webservice
integration between a Rack and a Rails application. Rack app should be
a soap server and Rails app should be a soap client. How to work on
it? Anybody here, please help me. Give some simple sample code to
handle soap application between this.

Re: Why env.object_id is different in each middleware?

2010-01-04T19:44:15Z

A workaround is creating an initial middleware (like rack-config), adding some
empty entries to env hash and latter, in other middlewares or final
application, using env["NEW_ENTRY"].replace.
Of course this is a hack as it's only valid if the new entry is a String or an
object supporting "replace".

Re: Why env.object_id is different in each middleware?

2010-01-04T00:58:18Z

Yes it does :)
Thanks.

Re: Why env.object_id is different in each middleware?

2010-01-04T00:50:22Z

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.
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

[PATCH] make Rack::Session::Cookie spec immune to Marshal changes

2009-12-31T20:19:29Z

Various versions/implementations of Ruby may Marshal data
differently. Instead of relying on a fragile test that
relies on exact byte sequence matches, just rely on existing
round-trip tests for the cookies.
---
> > �Otoh, I feel this test is so fragile that it's probably best to
> > �scrap it and rely on the round-trip tests...

Re: [PATCH] make Rack::Session::Cookie spec pass under 1.9.2dev

2009-12-31T10:15:15Z

[PATCH] make Rack::Session::Cookie spec pass under 1.9.2dev

2009-12-31T01:37:05Z

There appears to be a small change to the Marshal output
under 1.9.2dev that makes it output differently than
under 1.9.1. Tested with Ruby trunk r26127.
---
Otoh, I feel this test is so fragile that it's probably best to
scrap it and rely on the round-trip tests...
Pushed out to the "mri-1.9.2dev" branch of git://git.bogomips.org/rack

Re: Call for 1.1.0 release

2009-12-31T01:22:52Z

I sent the patches ad the end of this message to Christian which should
get test-spec mostly working under 1.9 (though I can't get test-spec to
pass its own tests).
Under all versions of Ruby I tested, the basic test suite fails
spec_rack_logger.rb:
<"Program started\nNothing to do!\n"> expected to be =~

Re: deferrable bodies in Rainbows!

2009-12-30T10:47:29Z

Rainbows! 0.90.1 should support deferrable bodies needed for async apps
on EM.
I stole the async_app.ru and async_tailer.ru examples from Thin and made
them a part of the integration tests (in t/t04??-*.sh).
The app.deferred?(env) isn't supported, yet. It's in the TODO and I
don't think many people use it... (correct me if I'm wrong).

deferrable bodies in Rainbows!

2009-12-26T23:27:32Z

Moving to rainbows list
Hi James, thhanks for the heads up.
Rainbows! doesn't handle deferrable bodies yet (I didn't look closely enough
the first time around), so it can't do everything Thin does with EM, yet.
It's already in the TODO, I'll make a mental note to work on it sooner.

Re: Call for 1.1.0 release

2009-12-26T14:41:23Z

Eric - I had a report from one of the async_sinatra users who tried out rainbows with EM, and found that the API didn't actually line up with what Thin was doing. I really want to devote some more time with this but I've been very busy. Sadly due to this I don't want to say stop, but, well, I want to say please check existing apps against it. I guess could you check async_*.ru from github.com/macournoyer/thin/ma ster/tree/examples/async_*.ru, as from what was reported, they're not working with the rainbows implementation of the deferrablebody hacks.

Re: Call for 1.1.0 release

2009-12-26T14:38:38Z

+1 we need to hold off, there's more to discuss in this area.