Server expects Content-Type header instead of Accept header

[jhaynie]

The generated code for server expects Header with Content-Type of either application/json or application/protobuf.

Servers deal with the Accept header to determine the accept response type and servers generate the Content-Type header based on this content of the media returned. https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

I can hack the client to send a Content-Type and it works but this doesn't seem to make sense to me.

(Happy to provide a PR that would check for Accept and fallback to Content-Type for backwards compat if you're in agreement)

[spenczar]

Content-Type is indeed a standard request header, not just for responses, per section 7 of RFC 2616: https://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html. In fact, it's encouraged by the RFC for HTTP 1.1. Quoth section 7.2.1:

Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body.

Content-Type makes sense here because it's the client informing the server about how to parse the data it's sending.

Now, you might say "the client should include an Accept header too, to be consistent." But Accept is merely a "MAY"-include header, and is not required. It's perfectly acceptable for Twirp to declare that servers respond with the same type as that of the Content-Type of the request.

If there's a practical impact this is having for you, feel free to keep discussing and we can explore how to resolve it.