Guidance about `Accept` header for servers

The protocol test RestJsonNoInputAllowsAccept caught my eye.

1. Where in the Smithy spec is it specified how servers should handle this header?
2. Should restJson1 servers reject requests if they don’t have Content-Type set and the Accept header is not set to any of these values?
3. Should servers accept requests that don’t specify Content-Type nor Accept, but whose body is empty?

[david-perez]

@adamthom-amzn Sounds good. That is in fact the same S3-like use case that a user of our sSDK wants to build: https://github.com/awslabs/smithy-rs/pull/1023#discussion_r777568429

But they’re using restXml, which currently also says that Content-Type MUST be application/octet-stream in the case of blob. Shall we change that too?

[adamthom-amzn]

I’m proposing we change the spec for blob to say the Content-Type can be anything, and handling of the content is delegated to the server implementation. Does this work for you?

My mental model is this: if I wanted to have a REST API for a content repository that could receive images or videos of many different formats, Content-Type is the natural way to convey that. application/octet-stream discards important data in this use-case, and blob would be the appropriate member choice.