Is there a registered media type for when using the structured clone extension

[lmaccherone]

Discussed in #65

^{Originally posted by lmaccherone January 16, 2023}
I have noticed that if you encode with the structured clone extension but attempt to decode without it, cbor-x throws an error. I'm building an API where every response body is encoded in cbor-x with the structured clone extension, and I wonder how best to tell clients precisely what encoding is being used. RFC 6839 says you should not use an unregistered suffix like application/vnd.my-app+cbor-sc, so for now; I'm just using application/vnd.my-app+cbor and giving good documentation. I'm also catching the error thrown by cbor-x and explicitly mentioning that you need to use the structured clone extension in my error response. Still, I wonder if there is a valid way to specify it in the Content-Type header.

[kriszyp]

I will leave the media type aspect for the discussion question, but what is the error you are getting? You shouldn't need the structuredClone flag to enable the value sharing tags that are used for structured clone referencing for the decoder, they should always be enabled. Usually the more pertinent thing that needs to be configured is how objects are represented, and whether they use CBOR maps or use record tags. And there is a different default for new Encoder().encode() (uses record tags for objects) than just encode() (use maps).

[lmaccherone]

After your comment above and some experimenting, I realize my original post was in error. If I encode with new Encoder({ structuredClone: true }).encode(), both new Ecoder({ structuredClone: true }).decode() and plain old decode() work. The error is the other way around.

I have to use new Encoder({ structuredClone: true }).encode() because I need duplicate object references preserved. I am still confused though about how I should specify the media type but I'll take that up in the discussion.