Sinatra 1.3.2 adds 'non request' params to params objects with some routes

[mattetti]

When using routes such as: /users/:id 2 'non request' params get injected in the params object (captures and splat to be more exact). That broke by param verification code which is checking the params against specific rules.

Could you please consider moving these values from the params hash?

Thanks

[jamiehodge]

This also crops up with Rack::Parser, which doesn't namespace its result. Various parsers choke on the arrays it finds in params.

I don't imagine this is a simple fix, as splats etc should be in params.

[jamiehodge]

Would it not be enough to include non-empty splats and captures?

[mattetti]

@jamiehodge sounds to me that doing that would mean that it would then only sometimes break things instead of always breaking. I'd prefer to not have the splats and captures in the params at all.

[yb66]

I've just found this problem too. I'd definitely prefer not to have splats and captures in the params, as per the behaviour in 1.3.1.

[dorkusprime]

Agreed . . . this is kind of a nasty pollution of expected params. What would happen if, for instance, I send in a 'captures' or 'splat' parameter from a GET or POST request?

answer: they get completely stepped on.

http://localhost:4567/api/test/test?splat=1&captures=1&a=1

yields this params object:

{"splat":[],"captures":["test","test"],"a":"1"}

[Phrogz]

+1 This just bit me. Although my code mostly ignores the extra params, it doesn't do well with non-string values (I was calling .strip! on every item, and the arrays broke that). It seems wrong to put these items in @params.

@dorkusprime That's really unfortunate.

[rkh]

Splat and captures have "sometimes" been in the params ever since 0.2.0, possibly earlier, so removing them would not be possible before 2.0. If you need access to the GET/POST for validation or because they are named splat, consider using request.params, request.GET or request.POST.

[pheino]

When using request.params paring params out of the URL don't seem to work once we upgraded to this version of Sinatra.

/policies/1/accept.xml

Does anyone know where this code lives or as to why request.params don't return the RESTFUL params? This used to work fine.

[rkh]

request.params never contained these, only params. Should we add them to request.params? I am not sure about that yet, since up until now request has been independent of the block you were in.

[pheino]

Probably not if Sinatra is going to inject it.

OR remove the splat and captures as that is really my pain point.

/policies/1/accept.xml

Policy.find(params[:id])

param[:id] # expected

param[:captures][:id] # not expected and causes API contract to be violated since we strictly enforce params to exactly what the API allows/expects any unexpected params result in an exception

[CloCkWeRX]

This or something very similar appears to have cropped up in 2.0.0 (params regularly contains 'captures' again); I'm unclear if it was intentional or a regression of this issue; and the only time its mentioned is in the changelog for 0.9.0(!) as being added in... which this bug disagrees with.

If its intended (http://www.sinatrarb.com/intro.html suggests yes); would it be possible to document in the changelog/readme?