content-type header set but no body

[andreineculau]

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

[justinsheehy]

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.

[andreineculau]

+1
Is a pull request the move forward?

[kellymclaughlin]

Sure, pull requests are always welcomed.