Reject DELETE requests with a body

[bvolpato]

According to issues #8217 and #5960, DELETE requests that contains a body should be rejected.

[clintongormley]

Hi @brunocvcunha

Thanks for the PR. This is slightly more complicated than just outright rejecting DELETE requests with body because the clear scroll API takes a body. I think we need to deprecate that form of the API and support eg POST _search/clear_scroll instead.

[javanna]

This change per se would be ok as it only rejects delete api calls with a body. Maybe we should define a better error message, but most important is that other apis should get the same change, pretty much every api that registers a DELETE endpoint:

• RestDeleteIndexAction
• RestIndexDeleteAliasesAction
• RestDeleteIndexTemplateAction
• RestDeleteStoredScriptAction
• RestDeleteSnapshotAction
• RestDeleteRepositoryAction
• RestDeletePipelineAction
• RestClearScrollAction
• RestDeleteSearchTemplateAction

If all of these API need to change, then we may want to make the change once in RestController rather than in each and every delete action. But before we make the generic change we have to address the clear scroll api as that one does something with the body when provided.

[javanna]

@clintongormley we also support deleting a scroll by providing the id as a query_string parameter. Isn't that enough? Do we have to add POST with a body?

[dadoonet]

@javanna I did not look at the code but delete by query needs a body, right?

[javanna]

delete by query doesn't seem to be registering a DELETE endpoint anymore, rather a POST. see https://github.com/elastic/elasticsearch/blob/master/modules/reindex/src/main/java/org/elasticsearch/index/reindex/RestDeleteByQueryAction.java#L45

[dadoonet]

oh? Thanks @javanna. I was not aware of that change.
Then I agree with your comment:

we may want to make the change once in RestController

[clintongormley]

we also support deleting a scroll by providing the id as a query_string parameter. Isn't that enough? Do we have to add POST with a body?

No it is not enough, unfortunately. It is quite easy to exceed the HTTP header length with clear-scroll requests against many shards

[bvolpato]

Thanks for the suggestions guys.

This handler is only registered for the /{index}/{type}/{id} endpoint. The _scroll requests get processed by RestClearScrollAction, which isn't included in this PR.

As of the message, I took some others as example, and it follows the same format/level of detail.
core/src/main/java/org/elasticsearch/rest/action/search/RestClearScrollAction.java: throw new IllegalArgumentException("Failed to parse request body", e);. Any suggestions? I think anything more than just "can't specify a request body" will become redundant.

I could extend the PR to other endpoints, and take a look on how this could be handled by the RestController itself, but there are some DELETE endpoints that require body as mentioned above, so I'm not sure if the controller should have this knowledge.

[jasontedor]

We prefer pull requests against our master branch.

[javanna]

hi @brunocvcunha thanks for your contribution!

The only delete endpoint left that requires a body is clear scroll, which we are going to deprecate in 5.x. We can then make the generic change to RestController safely in master (future 6.x) where no DELETE endpoint will require a body. I can work on the clear scroll changes needed in the coming days and you can take a spin at updating this PR if you are up for it.

I defer to @clintongormley for the error message that we want to return.

[clintongormley]

Re the exception message, how about: DELETE requests may not contain a request body?

[rjernst]

@brunocvcunha Are you interested in updating this PR given the suggestions made?

[elasticmachine]

Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

[rjernst]

Apologies, I see now you already made the suggested wording change. In the future, you should ping reviewers after updating a PR.

@elasticmachine test this please

[rjernst]

Ah, @brunocvcunha if you are still interested in this change, can you cherry pick to master and force push to this branch?

[javanna]

@rjernst this PR requires #21510 which is stalled as it requires #21888. I will label this PR as stalled for now. I need to find time to implement #21888 and then get #22510 in with proper tests. After that I will get back to this change.

[javanna]

why did you close this @martijnvg ?

[elasticmachine]

Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

[nik9000]

I get that this has been stalled for a long time, but do we have any chance of un-stalling it? Should we start fresh on the issue once we've unblocked the prerequisites? @brunocvcunha, are you still interested in this after all this time?

[elasticmachine]

Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

[javanna]

@nik9000 yea we have a chance to un-stall it if somebody gets to work on #21888 so that we can finally properly test bw comp against changes like this and #21510.

[jasontedor]

No additional feedback, closing.