Decoding with simple type 23 does not throw?

[achingbrain]

I have an object with a value type that is not supported by IPLD { "a": undefined }.

I can use cborg to encode it:

import * as cborg from 'cborg'
import * as ipldDagCbor from '@ipld/dag-cbor'
import { toString } from 'uint8arrays'

const obj = { a: undefined }

const cborgBytes = cborg.encode(obj)
console.info(toString(cborgBytes, 'hex'))
// a16161f7

cbor.me displays this as:

A1       # map(1)
   61    # text(1)
      61 # "a"
   F7    # primitive(23)

So far, so good.

@ipld/dag-cbor refuses to encode the object, which seems correct:

ipldDagCbor.encode(obj)
// Error: `undefined` is not supported by the IPLD Data Model and cannot be encoded

However @ipld/dag-cbor decodes the output of cborg just fine though converts undefined to null:

console.info(cborg.decode(cborgBytes))
// { a: undefined }
console.info(ipldDagCbor.decode(cborgBytes))
// { a: null }

I would have expected @ipld/dag-cbor to throw on decode when encountering a forbidden type instead of interpreting it as a different type?

[achingbrain]

Ok, this was allowed to support legacy data in #45

[achingbrain]

For reference I arrived here because I was debugging a test that used the multihash from a 0x51 (e.g. CBOR) CID stuffed into a 0x71 (e.g. DAG-CBOR) CID, and was trying to get the HTTP Gateway to convert the deserialized object into JSON.

The object has an undefined field so the test expects a 406 because that isn't representable in JSON but it was getting a 200 because @ipld/dag-cbor converts the undefined into null instead of erroring on decode.

JSON.stringify then ignores the null field which leaves you in a weird position where after the client deserializes the JSON to an object, it can't then round-trip that object back to (DAG)CBOR and end up with the same CID because one of the properties is missing, and worse - the client has no idea that it's missing even though nothing has errored up to this point.

The whole IPLD-format-conversion part of the Gateway spec is full of these weird footguns, hopefully we can remove it entirely and the client can mess around with raw blocks directly if they need this sort of feature.

[rvagg]

ooof #44 (comment)

yeah this sucks

but, one item on the wishlist has always been a "strict" mode on the codecs so you can make these decisions on decode, would that be helpful here? maybe we should just do that, I could probably dig up a list of things we could enforce, I started this in Go at one point but never had a good reason to land something and didn't believe anyone would actually care enough