Do we need to be more precise w.r.t. `contenttype`->`typemap` mapping?

[duglin]

E.g. does text/html;charset=utf-8 match text/html ?

Proposal: just the type/sub-type of header value (parameters are excluded, anything after the first ; is ignoed).

Algorithm:

• extract the media-type from the Resource's contenttype attribute by taking everything before the first ;
• Check user-defined typemap keys, if only one matched then return its value
• If more than one matches, and they're all the same 'value', then return that value
• if more than one matches, but they're not all the same value, then treat it as "binary"
• if none matches then check the default type map as defined by the spec (text/plain, app/json, *+json)
• the default ones MAY be overwritten thru an explicit entry in the typemap

Note that "" is a valid char in a media type. Do we need to support escaping "\" in the pattern? Case insensitive compares - rfc: The type and subtype tokens are case-insensitive.

Another scenario:

• user PUTs to a Resource with { "file": "hello" }, but no contenttype - do we treat this as binary or a string"
• what about {"file": { "foo": "bar" } } ? if it's binary, are we allowed to strip whitespaces (or pretty print) before we store the bytes?
• basically, if we know it's JSON on the input, can the server make any smart decisions despite no contenttype attribute?
• can it set "contenttype" to "app/json" automatically for the user? While I'm not a fan of touching the user's data, at least it would give them a clue as to why we're treating it as JSON and not binary. Otherwise, if we don't set "contenttype" we have no choice but to treat it as binary (per our previous decisions) - is that ok?

What if a user does PUT {"contenttype": "foo/bar", "file": { "foo": "bar" } } ?

Proposal:

• on input: if resource is inlined, then the server is free to pretty-print/strip whitespaces. Stores result as bytes.
  • no content-type: set it to app/json - PUT: even if it already has a value. PATCH: only if it has no value
  • has content-type: save it, as is
• on output:
  • no content-type: binary
  • app/json: json
  • text/plain: string
  • other: binary

[duglin]

Agreed to all except the need to escape "*" - it's not a valid char per the media-type/mime spec