Provide a way to opt-in to a full request payload on a DELETE request

[mwpastore]

As far as I can tell from reading RFCs, it is completely valid to send a full request payload (with a content-type) on a DELETE request. In fact, for example, the {json:api} spec depends on this functionality. The recent change to remove this capability from Rack::Test has crippled my ability to test {json:api}-conformant backends.

I can almost understand making the new default DELETE behavior send query params without a content-type, but there should be a way to opt-in to the old behavior.

[lanej]

request '/', method: :delete, input: "{}"

works.

Found here: https://github.com/rack-test/rack-test/blob/0047c07/spec/rack/test_spec.rb#L95

[mwpastore]

Ah, that certainly does the trick in the meantime. Thanks @lanej!

[dennissivia]

Seems as if this issue is already solved. If not, please reopen with the missing behaviour.

[perlun]

@scepticulous I don't think non-collaborators can reopen issues. @mwpastore did not seem happy about closing this, so I'm reopening now.

[mwpastore]

@perlun You read quite a lot into an emoji reaction! @lanej posted a workaround, but I'm not quite sure workaround===solution in this case. Falling back to request gets the job done, but I still think one should be able to use delete and opt-in to the old behavior.

[perlun]

You read quite a lot into an emoji reaction

😄 Sorry if i over-interpreted you. I just wanted to avoid us sending out the message that we close people's issues without they feeling that the issues are really resolved.

Falling back to request gets the job done, but I still think one should be able to use delete and opt-in to the old behavior.

Please suggest how the API could look to get it working and I think we can solve it. Maybe something like:

delete '/foo', '{}', payload: :body

Or perhaps someone can come up with something better?

[malacalypse]

Well, for now, if env['CONTENT_TYPE'] is "application/vnd.api+json" we should definitely be putting the params in the body, since that's a spec for that content type. This is a breaking change that has really caused a lot of trouble for us as well testing JSONAPI endpoints.

My suggestion for the long term is that there are "params" and there is a "body" and that if the body is set we do nothing with it other than pass it on, and if the params are set we put them either in the query string or in the body based on the method.

[morgoth]

This also caused regression in Rails apps rails/rails#30570

[perlun]

@malacalypse

Well, for now, if env['CONTENT_TYPE'] is "application/vnd.api+json" we should definitely be putting the params in the body, since that's a spec for that content type. This is a breaking change that has really caused a lot of trouble for us as well testing JSONAPI endpoints.

I think that makes sense. Would you like to submit a patch that makes it behave that way?

My suggestion for the long term is that there are "params" and there is a "body" and that if the body is set we do nothing with it other than pass it on, and if the params are set we put them either in the query string or in the body based on the method.

Also makes sense. Or we could just KISS and say that params are always query parameters and body is always request body, and not try to guess what is the right way to do it in each situation. That would be a useful change, IMHO, even though it will force the user to think a bit more about how to write their code. For 1.0, this would be my personal suggested approach though.

@morgoth

This also caused regression in Rails apps rails/rails#30570

Sorry for that. Bear in mind that rack-test has been very unmaintained for a long time, and we are trying to improve on that. We do intend to release a 1.0 release "quite soon", and by then we will aim for Semantic Versioning compliance. For now, some breakage is unfortunately possible at times, even though we will try to minimize it.