Yes Rails does. Calling request.params in Rails offloads Rack::Request
to parse the params and Rack::Request sticks its cache in
> 1. Each request object parses the parameters resulting in a doubling of
> 2. A middleware author must know which type of request object is being used
> in order to manipulate the params hash.
These are not problems if your custom request object inherits from
> What I'd like to propose is that we setup the params hash of Rack::Request
> to be in env['rack.params'] which could then be shared across request object
> inplementation. Rails, Merb, <insert framework here> can then make use of
> custom requirements, and prevent double parsing while allowing middleware to
> inpsect / inject keys and values.
The convention atm is to stuff your params in the rack request cache
"rack.request.form_hash". I agree, we should convert this from a
generic cache to a "spec" similar to rack.session. "rack.params"
sounds good too.
> The params hash should be hash like, and support accessing all keys via a
> string of the key name. (ie HashWithIndifferentAccess or Mash would work
I don't think we should require any special type of data structure.
Even better, just require that whatever object is in
env['rack.params'] respond to  and =.
env["action_dispatch.request.request_parameters"]Which means that on the way back up the stack the params hash is inaccessible to normal Rack::Request objects.
+1 on your proposal. Question: why not use the same structure we used for session? I think the only added things were key? and delete (not sure though).-- Yehuda
Sounds good to me.
Christian Neukirchen <chneuk...@gmail.com> http://chneukirchen.org
Daniel, do you want to write up the patch? We'll need to update Lint
to enforce the SPEC then update any other middleware appropriately.
I'll take it from there.
I'd say merge them. But I'm curious if there is any opposition.