-
-
Notifications
You must be signed in to change notification settings - Fork 901
Gpenverne fix/allow empty content on post and put requests #805
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
Gpenverne fix/allow empty content on post and put requests #805
Conversation
…x/allow-empty-content-on-post-and-put-requests
…tps://github.com/gpenverne/core into gpenverne-fix/allow-empty-content-on-post-and-put-requests
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.
👍
@@ -358,6 +358,9 @@ Feature: Create-Retrieve-Update-Delete | |||
"alias": null | |||
} | |||
""" | |||
Scenario: PUT request on custom operations without content |
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 scenario is incorrect. This is not a custom operation, and I don't suppose it should return 200 when the semantics is undefined (for the default PUT operation). Shouldn't it be 400 instead?
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.
Indeed it is incorrect. But why a 400 if we allow empty requests for PUT
, it should be allowed for all PUT
operations isn't it?
What does PUT with an empty body mean? The semantics are undefined. The On Tue, 18 Oct 2016, 13:52 Kévin Dunglas, notifications@github.com wrote:
|
Ok got what you mean. Not sure that we should add this in core. Maybe just a doc to explain how to do that would be enough? It's weird to have a different behavior for built-in and user-land operations. |
Ideally it should return 400 for both built-in and custom POST / PUT operations when an empty body is encountered, unless the user handles it in the custom operation. But yeah, I'm not sure how that can be implemented. So probably we should merge this as is. |
@teohhanhui why should it return a 400? Sending empty content is not an error! |
It really depends on the content type. For example, an empty string is NOT valid JSON. |
What is the status of this PR ? empty content has been allowed on PUT request via #1274 . @teohhanhui : You are right that empty string is an invalid JSON but POST method do send empty string as body if you don't specify one. For me this should be iso between all "unsafe" methods (except DELETE), if you send an error you should send errors on PUT, POST, PATCH, etc., but if you don't send an error, you should not send error at all. |
Follows #782. All credit go to @gpenverne.