-
Notifications
You must be signed in to change notification settings - Fork 251
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document how to use URL params with DELETE method #220
Conversation
Thanks for the effort @tpltn, much appreciated! Before we merge this, could you ensure that we also have a test for Thanks in advance. |
@perlun you are right: we cannot get payload body in this way. I’ll look at the |
Great, thanks! I also suggest:
|
RFC 7231 says:
This means that DELETE method can have payload body. rack-test sets url params or payload body with I suggest:
|
I'm inclined to say I agree to this. jquery/jquery#3269 seemed to have made the same decision a while ago. (years, literally) So:
Sorry for the messy state here, going a bit back and forth. Unless someone objects very strongly, this is the direction in which I intend to steer this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're getting there, thanks a lot for this @tpltn. With the suggested changes I think we are close to merging.
README.md
Outdated
|
||
def delete_with_url_params_and_body | ||
delete '/?foo=bar', JSON.generate('foo' => 'baz') | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This example is a bit messy. Using foo
both for the query parameter and the body value, that would be a bit messy on the receiving end.
Could you change it to be 'baz' => 'zot'
instead? That would make the example more clear.
it 'uses the provided params hash' do | ||
delete '/', foo: 'bar' | ||
expect(last_request.GET).to eq({}) | ||
expect(last_request.POST).to eq('foo' => 'bar') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the casual reader, it might not be entirely obvious that the body here is not JSON but instead multipart/form-encoded data. Would you mind adding a note about that, or a separate test that tests the content of last_request.body.read
?
...even when no parameters are provided (or the provided parameters are `nil`) The long story: - #132 changed the behavior for HTTP DELETE requests to behave like GET: put the parameters in the query string, and don't set the Content-Type. This change was merged in d016695 - This broke `rack-test` for certain people, which was highlighted in #200. Arguably, the change incorporated in d016695 was too brutal. - #212 tried to sort it out, by not setting Content-Type if params are nil, and also reverting the change to put DELETE parameters in the query string. The first part of this (params being nil) caused issues for certain people. So this PR now tries to once and for all sort this out by: - Always setting `env['CONTENT_TYPE']`, even when params are `nil`. - Adding more tests for how `CONTENT_TYPE` and `CONTENT_LENGTH` should behave; some of this does not come from us, but from Rack upstream. - Settles with the discussion in #220: if you are using `DELETE` and must use query params, put them manually in there like this: `delete '/foo?bar=baz'`. Arguably not very clean, but better than changing back and forth. `params` are overloaded in rack 0.x and will be so in 1.0 also. I am thinking that we should go with the excellent suggestion provided by @malacalypse in #200 to use dedicated `body` and `params` parameters in the long run (and probably use keyword parameters instead, but that's definitely a 2.x feature since it breaks all existing usage.) For now, I think we'll live with the ugliness. I encourage everyone to give this a try before we merge, to ensure we don't have to revert once more.
@perlun thanks for the review! I fixed all the remarks you listed. |
Thanks, merging this now. |
...even when no parameters are provided (or the provided parameters are `nil`) The long story: - #132 changed the behavior for HTTP DELETE requests to behave like GET: put the parameters in the query string, and don't set the Content-Type. This change was merged in d016695 - This broke `rack-test` for certain people, which was highlighted in #200. Arguably, the change incorporated in d016695 was too brutal. - #212 tried to sort it out, by not setting Content-Type if params are nil, and also reverting the change to put DELETE parameters in the query string. The first part of this (params being nil) caused issues for certain people. So this PR now tries to once and for all sort this out by: - Always setting `env['CONTENT_TYPE']`, even when params are `nil`. - Adding more tests for how `CONTENT_TYPE` and `CONTENT_LENGTH` should behave; some of this does not come from us, but from Rack upstream. - Settles with the discussion in #220: if you are using `DELETE` and must use query params, put them manually in there like this: `delete '/foo?bar=baz'`. Arguably not very clean, but better than changing back and forth. `params` are overloaded in rack 0.x and will be so in 1.0 also. I am thinking that we should go with the excellent suggestion provided by @malacalypse in #200 to use dedicated `body` and `params` parameters in the long run (and probably use keyword parameters instead, but that's definitely a 2.x feature since it breaks all existing usage.) For now, I think we'll live with the ugliness. I encourage everyone to give this a try before we merge, to ensure we don't have to revert once more.
* restore ability to set URL params for DELETE method * make DELETE method acts as POST * fix pr remarks
...even when no parameters are provided (or the provided parameters are `nil`) The long story: - rack#132 changed the behavior for HTTP DELETE requests to behave like GET: put the parameters in the query string, and don't set the Content-Type. This change was merged in rack@d016695 - This broke `rack-test` for certain people, which was highlighted in rack#200. Arguably, the change incorporated in rack@d016695 was too brutal. - rack#212 tried to sort it out, by not setting Content-Type if params are nil, and also reverting the change to put DELETE parameters in the query string. The first part of this (params being nil) caused issues for certain people. So this PR now tries to once and for all sort this out by: - Always setting `env['CONTENT_TYPE']`, even when params are `nil`. - Adding more tests for how `CONTENT_TYPE` and `CONTENT_LENGTH` should behave; some of this does not come from us, but from Rack upstream. - Settles with the discussion in rack#220: if you are using `DELETE` and must use query params, put them manually in there like this: `delete '/foo?bar=baz'`. Arguably not very clean, but better than changing back and forth. `params` are overloaded in rack 0.x and will be so in 1.0 also. I am thinking that we should go with the excellent suggestion provided by @malacalypse in rack#200 to use dedicated `body` and `params` parameters in the long run (and probably use keyword parameters instead, but that's definitely a 2.x feature since it breaks all existing usage.) For now, I think we'll live with the ugliness. I encourage everyone to give this a try before we merge, to ensure we don't have to revert once more.
Fix #219