Allow other methods than POST to be overridden

[gerhardj]

Our customer wants to send a PATCH request to our API with an override header of DELETE.

I thought of adding another optional configuration option similar to the header and param:

• override_all - allows all original methods to be overridden when an override param or header is set. Default: 0, Options: 1|0

When you accept this feature, we will hopefully get around to send a pull request.

[ap]

Our customer wants to send a PATCH request to our API with an override header of DELETE.

What’s the point…?

[gerhardj]

Well, it's basically just the way, their enterprise provisioning system works.

Actually, I got it wrong in my initial explanation. It allows DELETE but doesn't understand PATCH. Now our API expects a PATCH or PUT request with a content which sets our entity to the terminated state. Because of limitations on their system, they just can send us a DELETE request for this usecase.

And I would say, DELETE is in this case semantically closer, to what they want to achieve than POST.

Anyway, our system had already supported that, through "Catalyst::ActionRole::HTTPMethods". But the functionality was dropped in favour of this Middleware. So we actually experienced a "regression" here and had to patch our software ourselves. So having this new option would actually bring the functionality closer to what Catalyst users have had before.

[ap]

Now our API expects a PATCH or PUT request with a content which sets our entity to the terminated state.

Hmm. But a DELETE doesn’t have a request body. So what happens if the client sends one with an override to turn it into a PATCH? Doesn’t your app need logic somewhere to inject the request body (at least in effect)?

[gerhardj]

DELETE can have a request body, it's just not usually done. [1]

[ap]

So the client sends a DELETE with a body…?