-
Notifications
You must be signed in to change notification settings - Fork 281
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
content-type header set but no body #114
Comments
We check the resource for the media type and related parameters there in order to determine if the various Accept* request headers can be satisfied, so that a 409 can be returned if they cannot. Also, there are cases (such as a HEAD request) where a media type should be given even if there is no body. That said, I agree that these headers are superfluous and possibly confusing in some of the possible cases after this decision. One solution could be to store (via e.g. a wrcall set_metadata) the "chosen" media type and parameters in these decisions, but only add the actual headers much later. when it is more certain that they are relevant. I would not object to such a change. |
+1 |
Sure, pull requests are always welcomed. |
Has anyone looked into decision F6 ?
https://github.com/basho/webmachine/blob/master/src/webmachine_decision_core.erl#L279
Why set a content-type header when the response can easily be 204 No Content or 303 See Other or 201 Created, etc?
To take it further, why require content_types_provided to provide at least on content type if the resource does not respond with an entity?
Isn't setting a content-type header closer to O11, where the etag and body generation takes place?
https://github.com/basho/webmachine/blob/master/src/webmachine_decision_core.erl#L524
The text was updated successfully, but these errors were encountered: