For certain calls which return a 204 No Content response, the Accept header cannot be set to application/json. Attempting to include such an Accept header results in a 406 Not Acceptable response. I believe each of these calls should allow the user to specify the Accept header for the following reasons.
1. The Accept header is used for content negotiation which affects not only the resource representation, but also the content type for error messages. For the affected calls, the 406 response actually contains the Content-Type: application/json header.
2. The 204 response indicates that the client does not need to update its existing view of the document (or resource) in question. The Accept applies to serialization/deserialization of resource data, so a response with no content is equivalent to supporting any Accept header.
3. From a usability standpoint while developing an SDK, this is especially problematic because it requires special handling be added for all affected calls to remove the default Accept header which is added by the framework. It is normal to override the header for special cases (e.g. for JSON Patch), but removing the header in preparation for a 204 is not anticipated.
RFC 7231 is not clear about the manner in which the Accept header "should" be evaluated for calls that return a 204 response. In the absence of a directive to implement the calls in a particular manner, the service should choose to do so in the manner most usable to clients. In this case, it means updating all calls which return no content (regardless of response code) to allow the Accept header to be specified as (at minimum) application/json, or possibly allow any syntactically correct value for this header.
this affects the /ping endpoint